From ynir@checkpoint.com Tue Dec 1 02:06: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 093813A6A2C; Tue, 1 Dec 2009 02:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3LeS9TcE8dM; Tue, 1 Dec 2009 02:06:30 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F3F6E3A63D3; Tue, 1 Dec 2009 02:06:29 -0800 (PST) X-CheckPoint: {4B14E6A3-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 67EF129C008; Tue, 1 Dec 2009 12:06:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 49E4029C002; Tue, 1 Dec 2009 12:06:21 +0200 (IST) X-CheckPoint: {4B14E6A3-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 nB1A6KGo022925; Tue, 1 Dec 2009 12:06: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; Tue, 1 Dec 2009 12:06:27 +0200 From: Yoav Nir To: "ietf@ietf.org" Date: Tue, 1 Dec 2009 12:06:18 +0200 Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: AcpybfHMmvFP/j9QRVGxAqdKUE6NZg== Message-ID: <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.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 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: Tue, 01 Dec 2009 10:06:31 -0000 On Nov 30, 2009, at 5:37 PM, 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. I oppose publishing the current draft.=20 There are two unresolved issues still being discussed on the TLS mailing li= st:=20 1. non-extension signaling for older versions (SSLv3 and maybe TLS 1.0) 2. explicit vs implicit addition of old verify_data to the PRF (also known= as fail-unsafe vs fail-safe) I think the WG is converging, and that a couple of more weeks of discussion= may lead to consensus.=20 I agree with David-Sarah Hopwood that a last call (WG or IETF) is still pre= mature. From ynir@checkpoint.com Tue Dec 1 02:17: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 C59B028C0DD for ; Tue, 1 Dec 2009 02:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 jbjcHFVQ0iwH for ; Tue, 1 Dec 2009 02:17:32 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 87ECA3A683E for ; Tue, 1 Dec 2009 02:17:31 -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 nB1AHGGo027786; Tue, 1 Dec 2009 12:17: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, 1 Dec 2009 12:17:23 +0200 From: Yoav Nir To: " " Date: Tue, 1 Dec 2009 12:17:14 +0200 Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpyb3kNprPvwWFQQHmegQWsADJVqg== Message-ID: <2D9C122C-23B4-4284-93B2-FFADF33798C4@checkpoint.com> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@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 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: Tue, 01 Dec 2009 10:17:32 -0000 On Nov 30, 2009, at 10:38 PM, wrote: > >=20 >> As you say, no approach today is totally extension less, so the big >> difference remaining IMO is: >>=20 >> 1) The fail-unsafe approach based on sending verify_data in extensions. >>=20 >> 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) >>=20 >> Everything else is more or less the same. >=20 > 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. I think there should be some form of extension-less signaling from client t= o server, at least for SSLv3 and TLS 1.0 on the initial handshake. I also t= hink that it's a good idea to have some kind of server to client signaling = to show that no renegotiations are supported, but servers that support the = new, safe renegotiation should reply with an extension. Since the client pr= oposed it in the magic ciphersuite, the response extension is not unsolicit= ed.=20 > 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. >=20 > 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. The signaling issue may harm connectivity, and that's a hot button issue. v= erify_data over the wire has not-well-understood security implications, and= is mostly an implementation detail, so it generates less fervor. Still, I believe that anything that makes it harder for implementers to mes= s up on security is a good thing, so I do care very strongly about it. >=20 > 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). Just did. Yoav From stephen.farrell@cs.tcd.ie Tue Dec 1 03:36: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 4A9C53A688F; Tue, 1 Dec 2009 03:36:46 -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.071, 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 Dg8wMeywwIjh; Tue, 1 Dec 2009 03:36:45 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 4659F3A6819; Tue, 1 Dec 2009 03:36:45 -0800 (PST) Received: from mail174-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 8.1.340.0; Tue, 1 Dec 2009 11:36:37 +0000 Received: from mail174-tx2 (localhost.localdomain [127.0.0.1]) by mail174-tx2-R.bigfish.com (Postfix) with ESMTP id D0A9B1C503C4; Tue, 1 Dec 2009 11:36:37 +0000 (UTC) X-SpamScore: -40 X-BigFish: VPS-40(z1725nz1432R98dN1442J9371Pzz1202hz4fhz1033ILz2dh6bh87h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail174-tx2 (localhost.localdomain [127.0.0.1]) by mail174-tx2 (MessageSwitch) id 1259667394903599_10133; Tue, 1 Dec 2009 11:36:34 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.251]) by mail174-tx2.bigfish.com (Postfix) with ESMTP id D97001920055; Tue, 1 Dec 2009 11:36:34 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server id 14.0.482.32; Tue, 1 Dec 2009 11:36:33 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 2096468005; Tue, 1 Dec 2009 11:36:33 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A00D3B1329C; Tue, 01 Dec 2009 11:36:33 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id D6EE768005; Tue, 1 Dec 2009 11:36:32 +0000 (GMT) Message-ID: <4B14FFC0.3040404@cs.tcd.ie> Date: Tue, 1 Dec 2009 11:36:32 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: "ietf@ietf.org" References: <20091130153734.D44C63A6AA9@core3.amsl.com> <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com> In-Reply-To: <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A10D3B1329C 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.114.5) X-Reverse-DNS: imx2.tcd.ie Cc: "tls@ietf.org 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: Tue, 01 Dec 2009 11:36:46 -0000 Yoav Nir wrote: > On Nov 30, 2009, at 5: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. 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. > > I oppose publishing the current draft. I strongly support it. I don't buy the claims that extension handling as required here is so hard to implement and all clients & servers need modification in any case. (Not that its really relevant, but writing that code would be much easier that reading the recent TLS list traffic;-) I also don't see any concrete benefit in not sending the verify data over the wire, but I do see more possibility for error in terms of how to incorporate that data if its not sent. My comments on -01 are below. While I'd like to see these addressed of course, I think progressing this document speedily is more important than resolving my comments. I think the same applies to all other comments that I've seen, both during IETF LC and on the TLS list since this problem was announced. Regards, Stephen. 1. The reference for the HTTP splicing attack is still a placeholder. "[REF]" 2. I don't see any particular reason why the ServerHello RI value contains both client and server values. I think it'd be marginally better if the server just sent its value since the current approach makes it easier for a server to mess up the ordering. 3. (Crossing page 5/6) It says the both "MUST verify" that the values are correct, but doesn't explicitly say how to verify the values, but just "as specified below" - where below? It might be good to be extra-clear here, and add e.g. "A correct value is one that was the verify_data of the Finished message from the previous TLS session, or else the "empty" value given above." or something like that. 4. I'm slightly concerned that middleboxes might barf on the new ciphersuite. Be good if someone had tested that in the wild, but I've not seen a mail that says that that's happened. (The test I mean is inclusion of a totally new ciphersuite value, not the inclusion of a previously-allocated-but-mostly-unused value.) 5. (Similar to above.) It'd be great if we had data to allow us to recommend either the RI in the initial handshake or else recommend the ciphersuite. I can see implementers not knowing what to do there, leading to a 50-50 split in terms of who does what, possibly leading to lack of interop. If it were up to me, I'd remove the ciphersuite and just go with the RI. 6. Is there an explicit statement somewhere that servers MUST support both the RI extension and the ciphersuite? If so, I skipped over it, so maybe highlighting it somehow would be good. If not, please add, so that someone generating tests from the RFC's "MUST" statements generates one for that. 7. 6.2 says: "If servers wish to <> they MUST NOT <>" Isn't that equivalent to servers SHOULD NOT? I think a SHOULD NOT is better. (And that's the form used in section 7.) 8. I would be for removing the new requirement that the identity not change. This spec is in response to one thing and should only fix that thing. Any other considerations should not get the "emergency" treatment being applied here especially since there could be unforseen side-effects of the additional change. (E.g. some deployed application making use of an id-change.) 9. The security considerations and the introduction should include a statement that another mitigation that's useful in many cases is for a server to simply disallow all renegotiation and encourage implementers to allow deployments to control that. From james@manger.com.au Tue Dec 1 05:43: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 C2BF43A6927 for ; Tue, 1 Dec 2009 05:43:31 -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 mFTS-VUYf9cO for ; Tue, 1 Dec 2009 05:43:31 -0800 (PST) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by core3.amsl.com (Postfix) with ESMTP id D33033A687D for ; Tue, 1 Dec 2009 05:43:30 -0800 (PST) Received: from nschwotgx01p.mx.bigpond.com ([58.175.155.56]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20091201134322.NFOM4789.nschwmtas03p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Tue, 1 Dec 2009 13:43:22 +0000 Received: from [192.168.0.2] (really [58.175.155.56]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20091201134322.YNPN1743.nschwotgx01p.mx.bigpond.com@[192.168.0.2]> for ; Tue, 1 Dec 2009 13:43:22 +0000 From: James Manger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Dec 2009 00:43:17 +1100 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4B151D7A.0067,ss=1,fgs=0 Subject: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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 13:58:14 -0000 I strongly support the consistent identity check in the Security = Considerations section of draft-ietf-tls-renegotiation-01. There may be some niche uses of TLS for which changing an identity = during renegotiation makes sense. That is adequately supported by the = last paragraph in the Security Considerations: "A TLS library MAY = provide a means for the application to allow identity and/or server_name = changes across renegotiations...". However, for 99.9...% of TLS uses an = identity changing during renegotiation will be totally unexpected by the = higher-layer application and can only cause problems. A few people have argued that the consistent identity check is a = separate issue that should not be addressed now. I don't think that is a = fair characterisation. Even unpatched current TLS implementations can = unambiguously describe the authenticity and confidentiality of every = byte of application data. The bug only occurs because apps don't expect = a per-byte security context, but a per-TLS-connection security context. = Allowing the authenticated identity to change per-byte does not solve = this underlying mismatch between what almost all apps expect and what = TLS delivers. Keeping identity consistent does narrow this mismatch. James Manger= From stephen.farrell@cs.tcd.ie Tue Dec 1 06:38: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 249183A6A0C for ; Tue, 1 Dec 2009 06:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 VhccoFSj+meA for ; Tue, 1 Dec 2009 06:38:30 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 43FBF3A6A26 for ; Tue, 1 Dec 2009 06:38:30 -0800 (PST) Received: from mail127-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 8.1.340.0; Tue, 1 Dec 2009 14:38:22 +0000 Received: from mail127-tx2 (localhost.localdomain [127.0.0.1]) by mail127-tx2-R.bigfish.com (Postfix) with ESMTP id C7C151548480; Tue, 1 Dec 2009 14:38:22 +0000 (UTC) X-SpamScore: -6 X-BigFish: VPS-6(zz98dNzz1202hzzz2dh87h6bh61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail127-tx2 (localhost.localdomain [127.0.0.1]) by mail127-tx2 (MessageSwitch) id 1259678290183327_31082; Tue, 1 Dec 2009 14:38:10 +0000 (UTC) Received: from TX2EHSMHS004.bigfish.com (unknown [10.9.14.235]) by mail127-tx2.bigfish.com (Postfix) with ESMTP id 9BD4A1C4004F; Tue, 1 Dec 2009 14:38:09 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS004.bigfish.com (10.9.99.104) with Microsoft SMTP Server id 14.0.482.32; Tue, 1 Dec 2009 14:38:05 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id E483668005; Tue, 1 Dec 2009 14:38:04 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A05A88E07E5; Tue, 01 Dec 2009 14:38:04 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id D629D68007; Tue, 1 Dec 2009 14:38:04 +0000 (GMT) Message-ID: <4B152A4C.9070702@cs.tcd.ie> Date: Tue, 1 Dec 2009 14:38:04 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: James Manger References: 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 = A15A88E07E5 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.114.5) X-Reverse-DNS: imx2.tcd.ie Cc: tls@ietf.org Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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 14:38:31 -0000 James Manger wrote: > I strongly support the consistent identity check in the Security Considerations section of draft-ietf-tls-renegotiation-01. Fair enough. > There may be some niche uses of TLS for which changing an identity during renegotiation makes sense. That is adequately supported by the last paragraph in the Security Considerations: "A TLS library MAY provide a means for the application to allow identity and/or server_name changes across renegotiations...". However, for 99.9...% of TLS uses an identity changing during renegotiation will be totally unexpected by the higher-layer application and can only cause problems. I'd buy that. > A few people have argued that the consistent identity check is a separate issue that should not be addressed now. I don't think that is a fair characterisation. I'm not sure what you mean by "characterisation." My point was simply that this *is* a different issue from the renegotiation bug, that we're fixing that bug in "emergency" mode and that we therefore shouldn't change *anything* else whilst in that mode. To give one example - rfc 2712 says how to use kerberos with TLS. (I've no idea if that's really in use.) The text in -01 doesn't say how to handle that, but does have a MUST on no-change. That could break something. I don't want to hold the bug fix while we figure that out. I just thinks its safer to do this later with some other draft that UPDATEs 5246. Stephen. From marsh@extendedsubset.com Tue Dec 1 07:13: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 21AB03A687D for ; Tue, 1 Dec 2009 07:13:00 -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 bIr37Oa9sQ1g for ; Tue, 1 Dec 2009 07:12: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 F42293A6A0D for ; Tue, 1 Dec 2009 07:12: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 1NFUOr-000DKn-6p; Tue, 01 Dec 2009 15:12:21 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 040C7603C; Tue, 1 Dec 2009 15:12:17 +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/cdSABDlCdnattc/giIBauQxquECrGEe0= Message-ID: <4B153247.1030402@extendedsubset.com> Date: Tue, 01 Dec 2009 09:12:07 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> In-Reply-To: <200912010205.nB125SkT006982@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, 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 List-Id: "This is the mailing list 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 15:13:00 -0000 Martin Rex wrote: > 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. My point was simply that it could result in a lot of additional analysis, one which I think you've proven quite nicely. - Marsh From mrex@sap.com Tue Dec 1 08: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 80BC13A691D for ; Tue, 1 Dec 2009 08:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.127 X-Spam-Level: X-Spam-Status: No, score=-104.127 tagged_above=-999 required=5 tests=[AWL=2.122, 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 lXNHCG8VWagZ for ; Tue, 1 Dec 2009 08:34:37 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0B5253A6909 for ; Tue, 1 Dec 2009 08:34:35 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB1GYQh5018373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Dec 2009 17:34:26 +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: <20091201163001.ED8373A67A1@core3.amsl.com> Date: Tue, 1 Dec 2009 08:30: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 virwal06 X-SAP: out Subject: [TLS] I-D Action:draft-mrex-tls-secure-renegotiation-02.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: Tue, 01 Dec 2009 16:34: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, S. Santesson Filename : draft-mrex-tls-secure-renegotiation-02.txt Pages : 16 Date : 2009-12-01 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-01082706.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 jsalowey@cisco.com Tue Dec 1 10:32: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 C94D63A6984; Tue, 1 Dec 2009 10:32:49 -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 CAYlwmiLc-55; Tue, 1 Dec 2009 10:32:48 -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 A8DA63A6960; Tue, 1 Dec 2009 10:32:48 -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: ApoEAEPwFEurR7Ht/2dsb2JhbADAYpgWhDEEgWo X-IronPort-AV: E=Sophos;i="4.47,322,1257120000"; d="scan'208";a="443484544" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 01 Dec 2009 18:32:41 +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 nB1IWeki019386; Tue, 1 Dec 2009 18:32:41 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); Tue, 1 Dec 2009 10:32:32 -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, 1 Dec 2009 10:32:31 -0800 Message-ID: In-Reply-To: <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: AcpybfHMmvFP/j9QRVGxAqdKUE6NZgAQEVEw References: <20091130153734.D44C63A6AA9@core3.amsl.com> <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com> From: "Joseph Salowey (jsalowey)" To: "Yoav Nir" , X-OriginalArrivalTime: 01 Dec 2009 18:32:32.0237 (UTC) FILETIME=[A50EC9D0:01CA72B4] 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 18:32:49 -0000 I disagree that the last call is premature. I realize that not everyone is happy with all aspects of the current document but a clear majority of people on the TLS list have voiced their support for it. I do not see any consensus that the existing approach is flawed, nor do I see evidence of an emerging consensus on an alternative approach.=20 This document fixes a serious security hole in TLS and so it is important to finish it in a timely manner. While a minority of the WG may feel that it this draft isn't exactly the way it would like, it does address the relevant security issue. I don't feel that waiting several more weeks to see if consensus forms around some other approach is likely to be useful. Joe (Speaking as TLS Working Group Co-Chair) > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Yoav Nir > Sent: Tuesday, December 01, 2009 2:06 AM > To: ietf@ietf.org > Cc: tls@ietf.org Group > Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation=20 > (Transport LayerSecurity (TLS) Renegotiation Indication=20 > Extension) to Proposed Standard >=20 >=20 > On Nov 30, 2009, at 5:37 PM, The IESG wrote: >=20 > > The IESG has received a request from the Transport Layer Security WG > > (tls) to consider the following document: > >=20 > > - 'Transport Layer Security (TLS) Renegotiation Indication=20 > Extension ' > > as a Proposed Standard > >=20 > > The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > final comments on this action. Please send substantive comments to=20 > > the ietf@ietf.org mailing lists by 2009-12-14.=20 > Exceptionally, comments=20 > > may be sent to iesg@ietf.org instead. In either case, please retain=20 > > the beginning of the Subject line to allow automated sorting. >=20 > I oppose publishing the current draft.=20 >=20 > There are two unresolved issues still being discussed on the=20 > TLS mailing list:=20 > 1. non-extension signaling for older versions (SSLv3 and=20 > maybe TLS 1.0) 2. explicit vs implicit addition of old=20 > verify_data to the PRF (also known as fail-unsafe vs fail-safe) >=20 > I think the WG is converging, and that a couple of more weeks=20 > of discussion may lead to consensus.=20 >=20 > I agree with David-Sarah Hopwood that a last call (WG or=20 > IETF) is still premature. >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From stefan@aaa-sec.com Tue Dec 1 10:43: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 84C413A6946 for ; Tue, 1 Dec 2009 10:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 5DwFrfCSs2r2 for ; Tue, 1 Dec 2009 10:43:08 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 9657828C135 for ; Tue, 1 Dec 2009 10:43:08 -0800 (PST) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5747E28ACC7 for ; Tue, 1 Dec 2009 19:31:13 +0100 (CET) Received: (qmail 76305 invoked from network); 1 Dec 2009 18:31: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 s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 1 Dec 2009 18:31:06 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 01 Dec 2009 19:31:04 +0100 From: Stefan Santesson To: David-Sarah Hopwood , Message-ID: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: AcpytHB2RuF6yQ6WvU+5K7q7SSSP0Q== In-Reply-To: <4B14530C.5040403@jacaranda.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Tue, 01 Dec 2009 18:43:09 -0000 On 09-12-01 12:19 AM, "David-Sarah Hopwood" wrote: > 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. 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 > > 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. I agree to this. I will support the current draft-ietf-tls-renegotiation-01 if that is choice of direction in the end of this last call. However, the TLS working group has also been working hard to evaluate whether an alternative solution could provide better integration with legacy deployments and provide better security properties. This last call was initiated before the WG members had any real chance to express their choice of direction. For the sake of completeness, the alternative approach was updated and posted today and is available from: http://tools.ietf.org/html/draft-mrex-tls-secure-renegotiation-02 It is my opinion that this draft offers two noticeable advantages over draft-ietf-tls-renegotiation-01 1) By not sending verify data over the wire, this draft allows peers to fail-safe as a result of implementation errors in cases where a corresponding implementation error of draft-ietf-tls-renegotiation-01 leads to a fail-unsafe situation. 2) It offers a solution where servers never have to parse data from TLS extensions. This offers advantages when deploying the fix for legacy implementations. I would support if the choice of draft-mrex-tls-secure-renegotiation-02 as the selected solution to the problem, or an update of draft-ietf-tls-renegotiation-01 which incorporate the updated handshake message hash calculation of draft-mrex-tls-secure-renegotiation-02 as an alternative to sending verify data in the RI extensions. /Stefan From rrelyea@redhat.com Tue Dec 1 10:45: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 11A0428C158 for ; Tue, 1 Dec 2009 10:45:24 -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=[AWL=0.000, 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 gHb2iOC3+8dW for ; Tue, 1 Dec 2009 10:45:23 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id ECD1D28C154 for ; Tue, 1 Dec 2009 10:45: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 nB1IjFTM032731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Dec 2009 13:45:15 -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 nB1IjEcA016944 for ; Tue, 1 Dec 2009 13:45:15 -0500 Message-ID: <4B15643C.2070000@REDHAT.COM> Date: Tue, 01 Dec 2009 10:45:16 -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: <20091130153734.D44C63A6AA9@core3.amsl.com> In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000907040802070309080805" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21 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: Tue, 01 Dec 2009 18:45:24 -0000 This is a cryptographically signed message in MIME format. --------------ms000907040802070309080805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/30/2009 07:37 AM, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG=20 > (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,=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. > > 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&dT= ag=3D19412&rfc_flag=3D0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > =20 I support this draft. I'm not excited about an altogether different signaling strategy for SSL v3, but it's not a big enough issue to hold up this draft. The need is to great to have religious squabbles hold it up any longer. bob --------------ms000907040802070309080805 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 MTIwMTE4NDUxNlowIwYJKoZIhvcNAQkEMRYEFA61oztlBwZ7SafSgSE0O6TGFSlgMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBABDCy4m5hc+DQLENjgCf1LsKqQKEpbLomoTBh8FDoKUU3jQ5hEoW al4gTWO6/O4zhY63CMwWvkKfYV9HstVSul13KRuB04kEwiwf0u4cUEvPYWiRY9e9rU5hAFFq 65wvwqfxuaxThP4c4sa7b5R8JProcM2Ep+et2MhnCnnfGw8kFX19f84FWs4Toz0X+feJpQ9z 771XP5ZZS3qKTu+Y8IFTz2rY1QaB66f1E+EZJmOO8u9KeAQQSwUV1k/yaP/vNSoeQBYkOkP0 a6dHCm1PiW9tkW/dEdB3wzWZvUPrQ6+7O1WKsL0xCV/dTKNrjqDIdUzd456Bc0ULGg1wgfZD 0DgAAAAAAAA= --------------ms000907040802070309080805-- From Nicolas.Williams@sun.com Tue Dec 1 11:04: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 29AB83A6971 for ; Tue, 1 Dec 2009 11:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.755 X-Spam-Level: X-Spam-Status: No, score=-5.755 tagged_above=-999 required=5 tests=[AWL=0.291, 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 ooLqLFHpo20w for ; Tue, 1 Dec 2009 11:04:21 -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 471CD3A6972 for ; Tue, 1 Dec 2009 11:04: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 nB1J49AT004189 for ; Tue, 1 Dec 2009 19:04: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 nB1J49UK049983 for ; Tue, 1 Dec 2009 12:04: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 nB1IqQI5008034; Tue, 1 Dec 2009 12:52:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB1IqQOL008033; Tue, 1 Dec 2009 12:52:26 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Dec 2009 12:52:25 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091201185225.GH773@Sun.COM> References: <20091130210555.D8EA76C3EE1@kilo.networkresonance.com> <20091201031144.C11756C4000@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091201031144.C11756C4000@kilo.networkresonance.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: Tue, 01 Dec 2009 19:04:22 -0000 On Mon, Nov 30, 2009 at 07:11:43PM -0800, Eric Rescorla wrote: > 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. Not so: the Finished messages will necessarily fail to verify (assuming that the verify_data computations are cryptographically strong). No additional checking is needed anywhere. Nico -- From Nicolas.Williams@sun.com Tue Dec 1 11:10: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 615B43A68D9 for ; Tue, 1 Dec 2009 11:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.277, 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 7ZsSbtlMu1zy for ; Tue, 1 Dec 2009 11:10:32 -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 2CC0F3A6899 for ; Tue, 1 Dec 2009 11:10:27 -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 nB1JAJUm006006 for ; Tue, 1 Dec 2009 19:10:19 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 nB1JAJWf055065 for ; Tue, 1 Dec 2009 12:10:19 -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 nB1Ip6b0008027; Tue, 1 Dec 2009 12:51:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB1Ip5N6008026; Tue, 1 Dec 2009 12:51:05 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Dec 2009 12:51:05 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091201185104.GG773@Sun.COM> References: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> <4B153247.1030402@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B153247.1030402@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: Tue, 01 Dec 2009 19:10:33 -0000 On Tue, Dec 01, 2009 at 09:12:07AM -0600, Marsh Ray wrote: > Martin Rex wrote: > > 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. > > > > [...] > > My point was simply that it could result in a lot of additional > analysis, one which I think you've proven quite nicely. We'd better have a "formal cryptographic review" no matter what we do. Claiming that we'd to have one as an argument against a particular solution seems like a fallacy. I should stop at that, but the analysis of the prefix attack is simple and, most importantly, interesting enough, at least at first glance. 1) If there's such a prefix attack then we already have it because the hello messages come first in the hash that is used in the verify_data computation. I.e., a prefix attack is orthogonal to the re-negotiation problem and solutions. 2) The client's hello comes first, and it includes the client's nonce, so there's no prefix attack on clients -- there could only be a prefix attack on servers. 3) A prefix attack on servers is useless in mounting the attacks we have with the re-negotiation vulnerability: the client and server will be able to distinguish re-negotiations from initial ones as long as we do the channel binding thing, and there's no way that the MITM can defeat this by manipulating the verify_data computations for its connection to the server (the server will want to use CB for the re-negotiation, while the client won't, which will necessarily result in failure). 5) Yes, the MITM can modify the inner negotiation's handshake messages, and if the MITM can create collisions at will and in real-time then the MITM could win, but this would be not a result of the RI proposal nor any variation thereof, but a fundamental weakness in TLS resulting from the use of fundamentally weak hash functions. 6) Yes, the client hello starts with a constant (client_version) and a predictably changing item (gm_time) -- a total of 48 bits that could be used to mount a prefix collision attack. But 48-bits is less than all current hash function block sizes, and the next item is the client's nonce, which is 28 bytes. Collision attacks on hash functions would have to work with just a 48-bit prefix, or less! (Or client PRNGs would have to be broken, but then you have other problems anyways.) Nico -- From marsh@extendedsubset.com Tue Dec 1 11:58: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 2AF7D3A695A for ; Tue, 1 Dec 2009 11:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXdFu9XvKggk for ; Tue, 1 Dec 2009 11:58: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 370EF3A6822 for ; Tue, 1 Dec 2009 11:58: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 1NFYrn-000G7d-Ak; Tue, 01 Dec 2009 19:58:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E76CA603C; Tue, 1 Dec 2009 19:58: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/bFO5yKgop6ZkCZrcmmjDRxRRD0m/gMzI= Message-ID: <4B157559.3050405@extendedsubset.com> Date: Tue, 01 Dec 2009 13:58:17 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> <4B153247.1030402@extendedsubset.com> <20091201185104.GG773@Sun.COM> In-Reply-To: <20091201185104.GG773@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] 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 19:58:40 -0000 Nicolas Williams wrote: > On Tue, Dec 01, 2009 at 09:12:07AM -0600, Marsh Ray wrote: >> Martin Rex wrote: >>> 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. >>> >>> [...] >> My point was simply that it could result in a lot of additional >> analysis, one which I think you've proven quite nicely. > > We'd better have a "formal cryptographic review" no matter what we do. > Claiming that we'd to have one as an argument against a particular > solution seems like a fallacy. Proposals to change the hash calculations definitely reach deeper into than a hello extension which simply passes a duplicate value for bitwise comparison. > I should stop at that, but the analysis of the prefix attack is simple > and, most importantly, interesting enough, at least at first glance. I, too, find the idea deeply appealing. Unfortunately, we cannot compare the alternatives against perfection. The status quo is a horribly broken, vulnerable protocol and perhaps billions of affected systems. Every day that goes by, the attacks get better and more sites simply disable what is otherwise a useful feature. If anyone has a serious deficiency in draft-ietf-tls-renegotiation (either a correct implementation of it doesn't thoroughly fix the problem, it can't be implemented correctly by competent maintainers, or it can't be deployed by existing sites) then please point it out to me. I am willing to change my support, but it needs to be better than "it's 12 unnecessary bytes" or "an incompetent implementor could forget to compare the hashes". We have have had multiple implementations of this draft sitting on the shelf for almost a month now. Some of them have done interop testing and even simulated verify_data mismatches (nobody forgot to do the comparison). It has never been the intention to bypass or rubber-stamp the open review process, but still this "running code" has got to count for something. > 1) If there's such a prefix attack then we already have it because > the hello messages come first in the hash that is used in the > verify_data computation. I.e., a prefix attack is orthogonal to the > re-negotiation problem and solutions. > > 2) The client's hello comes first, and it includes the client's nonce, > so there's no prefix attack on clients -- there could only be a prefix > attack on servers. > > 3) A prefix attack on servers is useless in mounting the attacks we > have with the re-negotiation vulnerability: the client and server will > be able to distinguish re-negotiations from initial ones as long as we > do the channel binding thing, and there's no way that the MITM can > defeat this by manipulating the verify_data computations for its > connection to the server (the server will want to use CB for the > re-negotiation, while the client won't, which will necessarily result in > failure). > > 5) Yes, the MITM can modify the inner negotiation's handshake > messages, and if the MITM can create collisions at will and in real-time > then the MITM could win, but this would be not a result of the RI > proposal nor any variation thereof, but a fundamental weakness in TLS > resulting from the use of fundamentally weak hash functions. > > 6) Yes, the client hello starts with a constant (client_version) and a > predictably changing item (gm_time) -- a total of 48 bits that could be > used to mount a prefix collision attack. But 48-bits is less than all > current hash function block sizes, and the next item is the client's > nonce, which is 28 bytes. Collision attacks on hash functions would > have to work with just a 48-bit prefix, or less! (Or client PRNGs would > have to be broken, but then you have other problems anyways.) Or you could just use memcmp(). - Marsh From mrex@sap.com Tue Dec 1 12:05: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 C68963A6890 for ; Tue, 1 Dec 2009 12:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 rAy-SFWRNgQZ for ; Tue, 1 Dec 2009 12:05: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 930C93A67B8 for ; Tue, 1 Dec 2009 12:05:56 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB1K5lvC005288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Dec 2009 21:05:47 +0100 (MET) From: Martin Rex Message-Id: <200912012005.nB1K5lHF012737@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Tue, 1 Dec 2009 21:05:47 +0100 (MET) In-Reply-To: <20091201163001.ED8373A67A1@core3.amsl.com> from "Internet-Drafts@ietf.org" at Dec 1, 9 08:30: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 Subject: Re: [TLS] I-D Action:draft-mrex-tls-secure-renegotiation-02.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, 01 Dec 2009 20:05:57 -0000 Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : Transport Layer Security (TLS) Secure Renegotiation > Author(s) : M. Rex, S. Santesson > Filename : draft-mrex-tls-secure-renegotiation-02.txt > Pages : 16 > Date : 2009-12-01 I have submitted another update of the draft I've been working on together with Stefan Santesson. The S->C signaling now uses a TLS extension, C->S signaling is still with special cipher suite. (I have one implementor feedback for a defect in the octet string representing the encoded TLS extension in section 4.4. The length field for the Extension vector is missing, so it should be a 7-octet string 00 05 MSB LSB 00 01 00 rather than 5-octet). I have added the following paragraph to the Security Considerations about the controversally discussed "identity change during renegotiation": For some applications the possibility for a change in the remote peer's authenticated identity during a TLS renegotiation may be a vital requirement. For other applications it is impossible to cope with a change of the remote peer's previously authenticated identity during renegotiation. It is recommended that TLS implementations offer to applications the option to either disable renegotiation or to abort renegotiations where the remote peer tries to replace a previously authenticated certificate with a different one during renegotiation. -Martin From Nicolas.Williams@sun.com Tue Dec 1 13: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 440CE3A6890 for ; Tue, 1 Dec 2009 13:46:11 -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.265, 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 tZkIdCgXpUH9 for ; Tue, 1 Dec 2009 13:46:10 -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 6AE413A679C for ; Tue, 1 Dec 2009 13:46:10 -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 nB1Lk2du009256 for ; Tue, 1 Dec 2009 21:46: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 nB1Lk2up037226 for ; Tue, 1 Dec 2009 14:46: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 nB1LQjwb008146; Tue, 1 Dec 2009 15:26:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB1LQhlL008145; Tue, 1 Dec 2009 15:26:43 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Dec 2009 15:26:43 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091201212642.GM773@Sun.COM> References: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> <4B153247.1030402@extendedsubset.com> <20091201185104.GG773@Sun.COM> <4B157559.3050405@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B157559.3050405@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: Tue, 01 Dec 2009 21:46:11 -0000 On Tue, Dec 01, 2009 at 01:58:17PM -0600, Marsh Ray wrote: > Or you could just use memcmp(). No, that's a problem: implementors might forget and still interop. An implementor that forgets to insert the channel binding data where it belongs will simply fail to interop, thus they will not forget. From marsh@extendedsubset.com Tue Dec 1 14: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 7DEFB3A685E for ; Tue, 1 Dec 2009 14:05:00 -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 Ke3pCU817VVV for ; Tue, 1 Dec 2009 14:04:59 -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 AE8A93A682C for ; Tue, 1 Dec 2009 14:04:59 -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 1NFaq3-0008E7-R5; Tue, 01 Dec 2009 22:04:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3D177603C; Tue, 1 Dec 2009 22:04: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//nC7Rk2dbnYRCzWc7X8sWvT2ro1bFIxk= Message-ID: <4B1592F5.2050706@extendedsubset.com> Date: Tue, 01 Dec 2009 16:04:37 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> <4B153247.1030402@extendedsubset.com> <20091201185104.GG773@Sun.COM> <4B157559.3050405@extendedsubset.com> <20091201212642.GM773@Sun.COM> In-Reply-To: <20091201212642.GM773@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] 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 22:05:00 -0000 Nicolas Williams wrote: > On Tue, Dec 01, 2009 at 01:58:17PM -0600, Marsh Ray wrote: >> Or you could just use memcmp(). > > No, that's a problem: implementors might forget and still interop. An Again, they could also forget to check Finished.verify_data and many other conditions. No one wanted to add another thing to get right just for the fun of it, but at the end of the day draft-ietf-tls-renego is a relatively simple fix for a pretty deep problem. Personally, I think we should be grateful to get off so easy. > implementor that forgets to insert the channel binding data where it > belongs will simply fail to interop, thus they will not forget. The existence of publicly-available exploit code will help them to not forget. Someone posted some to the full-disclosure list in early November. Developers can just modify a byte in the debugger and watch the remote behavior. QA testers (and other interested parties) could benefit from a tool. I've refused all requests for my exploit code, but it seems like we could come up with a test client or server that merely simulated an incoming exploit by handling a renegotiation with an empty or incorrect extension data. This would give product testers something to work with. - Marsh From Nicolas.Williams@sun.com Tue Dec 1 14:23: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 CC2F93A6926 for ; Tue, 1 Dec 2009 14:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.254, 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 SaGX1QC6fGEk for ; Tue, 1 Dec 2009 14:23:08 -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 EF3FF3A68DE for ; Tue, 1 Dec 2009 14:23:07 -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 nB1MN0nB016123 for ; Tue, 1 Dec 2009 22:23:00 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 nB1MMxgA000387 for ; Tue, 1 Dec 2009 15:22: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 nB1M3kwG008171; Tue, 1 Dec 2009 16:03:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB1M3k8s008170; Tue, 1 Dec 2009 16:03:46 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Dec 2009 16:03:46 -0600 From: Nicolas Williams To: Marsh Ray Message-ID: <20091201220346.GP773@Sun.COM> References: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> <4B153247.1030402@extendedsubset.com> <20091201185104.GG773@Sun.COM> <4B157559.3050405@extendedsubset.com> <20091201212642.GM773@Sun.COM> <4B1592F5.2050706@extendedsubset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1592F5.2050706@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: Tue, 01 Dec 2009 22:23:08 -0000 On Tue, Dec 01, 2009 at 04:04:37PM -0600, Marsh Ray wrote: > Nicolas Williams wrote: > > On Tue, Dec 01, 2009 at 01:58:17PM -0600, Marsh Ray wrote: > >> Or you could just use memcmp(). > > > > No, that's a problem: implementors might forget and still interop. An > > Again, they could also forget to check Finished.verify_data and many > other conditions. No one wanted to add another thing to get right just > for the fun of it, but at the end of the day draft-ietf-tls-renego is a > relatively simple fix for a pretty deep problem. Personally, I think we > should be grateful to get off so easy. They were already checking the finished messages, thus this is not a new check. The issue is moot however, I think. As I've said, I think we can all live with this issue -- it's unfortunate, but hardly fatal. I've indicated my support for the RI proposal. Nico -- From mrex@sap.com Tue Dec 1 14:58: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 13F623A682C for ; Tue, 1 Dec 2009 14:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.208 X-Spam-Level: X-Spam-Status: No, score=-104.208 tagged_above=-999 required=5 tests=[AWL=2.041, 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 WCwbqTT-otbx for ; Tue, 1 Dec 2009 14:58: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 034F33A6783 for ; Tue, 1 Dec 2009 14:58:27 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB1MwIbe024783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Dec 2009 23:58:18 +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: <20091201214501.73D4D3A691E@core3.amsl.com> Date: Tue, 1 Dec 2009 13:45: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-03.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: Tue, 01 Dec 2009 22:58:29 -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, S. Santesson Filename : draft-mrex-tls-secure-renegotiation-03.txt Pages : 16 Date : 2009-12-01 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-01134414.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 djhopwood@googlemail.com Tue Dec 1 16:57: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 3A8C33A69D4 for ; Tue, 1 Dec 2009 16:57: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stnt025I0mao for ; Tue, 1 Dec 2009 16:57:25 -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 719363A6898 for ; Tue, 1 Dec 2009 16:57:05 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1056347eya.5 for ; Tue, 01 Dec 2009 16:56: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=c8zV/quJnSr8ktDIIuVx693xRV5WkDn/VCzk54NRCLI=; b=l4jX/mO3r31yDBpsKMrhOZ9KLnQQ86QHukDcb+br2HxogIVspWzIdAjXBM1e/AX1S5 6fZvHmO8/dM9WmR+Hoolk+fFeX8qhDrCtAuEJjoi2SG9CRY2sVuOLg+rh1EKlkOz3xzn 2ceMKd3V6AY5tMCPDVx3bdc28ZrKGg8piyFtI= 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=W1hvlrOw7xF17fu2kIaxYd/HCigRNkkUV1ooCrorfJREkQQEDAQAwyvGtRUnhrjVYw 99e6TiIQk3Xy0xqeutsctEnOzUxAnKxNYg9WrWtFkC73Z8SNkq8X3dr9UGJWWvBNK01Q i4qWf+K9MwivF91G0XcZmE2Wfp5B1z7RFHcN8= Received: by 10.213.0.144 with SMTP id 16mr7135439ebb.37.1259715413781; Tue, 01 Dec 2009 16:56:53 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 24sm1409458eyx.30.2009.12.01.16.56.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 16:56:53 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B15BB42.9080205@jacaranda.org> Date: Wed, 02 Dec 2009 00:56:34 +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: <200912012005.nB1K5lHF012737@fs4113.wdf.sap.corp> In-Reply-To: <200912012005.nB1K5lHF012737@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig27600CB0BCDB240813007900" Subject: Re: [TLS] I-D Action:draft-mrex-tls-secure-renegotiation-02.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, 02 Dec 2009 00:57:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27600CB0BCDB240813007900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > I have added the following paragraph to the Security Considerations abo= ut > the controversially discussed "identity change during renegotiation": >=20 > For some applications the possibility for a change in the remote > peer's authenticated identity during a TLS renegotiation may be a > vital requirement. For other applications it is impossible to cope > with a change of the remote peer's previously authenticated identity= > during renegotiation. It is recommended that TLS implementations > offer to applications the option to either disable renegotiation or > to abort renegotiations where the remote peer tries to replace a > previously authenticated certificate with a different one during > renegotiation. Looks good to me, but I suggest "recommended" -> "RECOMMENDED". --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig27600CB0BCDB240813007900 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/ iF4EAREIAAYFAksVu08ACgkQWUc8YzyzqAc44gD9FaVl+nKhJo0PAsWSJiRkw60p JNgflZ7QDH91++vQQn0A/j/ABfhpM6ye8Lh5gfHtsU7H6NOdXndLfYltzFRQfUPz =an2+ -----END PGP SIGNATURE----- --------------enig27600CB0BCDB240813007900-- From mrex@sap.com Tue Dec 1 17: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 002433A6880 for ; Tue, 1 Dec 2009 17:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 sznB77dWRlLY for ; Tue, 1 Dec 2009 17: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 F3FC83A6863 for ; Tue, 1 Dec 2009 17:23:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB21NhRF006191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Dec 2009 02:23:43 +0100 (MET) From: Martin Rex Message-Id: <200912020123.nB21NgDX002326@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 2 Dec 2009 02:23:42 +0100 (MET) In-Reply-To: <20091201214501.73D4D3A691E@core3.amsl.com> from "Internet-Drafts@ietf.org" at Dec 1, 9 01:45: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-03.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, 02 Dec 2009 01:23:53 -0000 Internet-Drafts@ietf.org wrote: > > Title : Transport Layer Security (TLS) Secure Renegotiation > Author(s) : M. Rex, S. Santesson > Filename : draft-mrex-tls-secure-renegotiation-03.txt > Pages : 16 > Date : 2009-12-01 I'm sorry for making two updates today. I fixed the fixed octet string representation of the data that goes into the (Extended)ServerHello in order to represent the TLS extension. I also changed the newly added TLS extension to be empty instead of containing a single-valued enum. For those who have not used the tools provided by the IETF archive, there is an online diff available to compare revisions of a document: Entry-point for my draft is here: http://tools.ietf.org/html/draft-mrex-tls-secure-renegotiation-03 The [Diff1] and [Diff2] show you the difference to the previous revision of the draft. -Martin PS: For the TLS WG document this would be http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 From mrex@sap.com Tue Dec 1 18: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 A7ADA3A6813; Tue, 1 Dec 2009 18:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 cBLf3ceFmlLp; Tue, 1 Dec 2009 18:50: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 45F5D3A679F; Tue, 1 Dec 2009 18:50:10 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB22nxnH014788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 03:49:59 +0100 (MET) From: Martin Rex Message-Id: <200912020249.nB22nvQ0007879@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Wed, 2 Dec 2009 03:49:57 +0100 (MET) In-Reply-To: <4B14FFC0.3040404@cs.tcd.ie> from "Stephen Farrell" at Dec 1, 9 11:36: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: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 02 Dec 2009 02:50:11 -0000 Stephen Farrell wrote: > > 7. 6.2 says: "If servers wish to <> they MUST > NOT <>" Isn't that equivalent to servers SHOULD > NOT? I think a SHOULD NOT is better. (And that's the form > used in section 7.) This might be confusion with ISO terminology. MUST == SHALL MUST NOT == SHALL NOT SHOULD == RECOMMENDED SHOULD NOT == NOT RECOMMENDED The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. And btw. the document that standardizes the secure renegotiation will have to say that it updates RFC-5246, because it needs to. -Martin From stpeter@stpeter.im Tue Dec 1 19:07: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 D7C913A69E2 for ; Tue, 1 Dec 2009 19:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51XwHDnRN+-f for ; Tue, 1 Dec 2009 19:07:27 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 728593A69EE for ; Tue, 1 Dec 2009 19:07:07 -0800 (PST) Received: from squire.local (dsl-205-34.dynamic-dsl.frii.net [216.17.205.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4853040D16; Tue, 1 Dec 2009 20:06:59 -0700 (MST) Message-ID: <4B15D9D2.3010107@stpeter.im> Date: Tue, 01 Dec 2009 20:06:58 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: rms@gnu.org References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> In-Reply-To: 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="------------ms060900060700040604050709" Cc: ietf-honest@lists.iadl.org, Todd Glassey , 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 List-Id: "This is the mailing list 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, 02 Dec 2009 03:07:28 -0000 This is a cryptographically signed message in MIME format. --------------ms060900060700040604050709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/30/09 9:09 PM, Richard Stallman wrote: > 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? Agreed, the term "intellectual property" is only bound to lead to muddled thinking. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060900060700040604050709 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 hvcNAQkFMQ8XDTA5MTIwMjAzMDY1OFowIwYJKoZIhvcNAQkEMRYEFBhEGU/hdK2TJJb+VDwH CAaf+qmRMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAiL8KvWWzdiPtTxpvl7NQN3kvG3f8np+pODWlbwHr RmFXnciWRMs9JhbBtlwIVaiJYxWs/i0XeJytE7femCDqlD7vsQHnJSFO/izY0hOv8aGUeVEf 2/dtSKfbU4a7FFvNhl1MPVf0fp1AqjEy/gPcx9IfftxGWzLzGQ/Rt1Ag8cU+RpwVJv9ZsnXK 8iMcy38PGAhuiN8m+6YWk8sAOfrF6tr55VmBKieawPn1nO3ien0Pu/87vy91Nf+GVPYdoi7o 5urrk0cZkMnOH/d3HpimjctGXmPqyhRUtnRUsKc9J4fX4HB09zwFigV8Q42wv5ZvZD/oY3u6 RJr5doypLH9fSwAAAAAAAA== --------------ms060900060700040604050709-- From mrex@sap.com Tue Dec 1 19:29: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 373223A6774 for ; Tue, 1 Dec 2009 19:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 wOrPswr5Rxf1 for ; Tue, 1 Dec 2009 19:29: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 2C31C3A682D for ; Tue, 1 Dec 2009 19:29:35 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB23TNUi017554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 04:29:23 +0100 (MET) From: Martin Rex Message-Id: <200912020329.nB23TMcL010059@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Wed, 2 Dec 2009 04:29:22 +0100 (MET) In-Reply-To: <6b9359640911301019w114a2a46m32c16afb2cb26067@mail.gmail.com> from "Kyle Hamilton" at Nov 30, 9 10:19:45 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: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 02 Dec 2009 03:29:36 -0000 Kyle Hamilton wrote: > > 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. It has been previously mentioned: this is likely an insufficiently clear wording of the spec. The TLS_RENEGO_PROTECTION_REQUEST cipher suite value is _not_ a means to request secure renegotiation (for the TLS extension RI, only the extension containing the verify_data is such a request). The purpose of the magic cipher suite is a request for protection from the _INsecure_ or "old" renegotiation. The spec should explicitly say that every updated/conforming client MUST add that cipher suite value into every ClientHello handshake message that it sends out, and that includes clients that do not implement renegotiation or have it disabled. That decision MUST be free from policy and configuration. In the attack scenario depicted in the document, the client only sees an initial TLS handshake an no renegotiation. The same applies to the servers. The document should explicitly say that servers MUST return the empty TLS renegotiation when the client requested it (by including the magic cipher suite value in the ClientHello). That includes servers that do not implement renegotiation or have it disabled. That decision MUST be free from policy and configuration. -Martin From marsh@extendedsubset.com Tue Dec 1 19:45: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 4DAB43A682D for ; Tue, 1 Dec 2009 19:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6rn-KXGgkbQ for ; Tue, 1 Dec 2009 19:45: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 5A2F03A67AE for ; Tue, 1 Dec 2009 19:45: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 1NFg9m-000O5z-W5; Wed, 02 Dec 2009 03:45:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2DD44603C; Wed, 2 Dec 2009 03:45: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: U2FsdGVkX19Wup32S0epEDVlh6/g5Uuo5+CBnb7zi74= Message-ID: <4B15E2DD.3000701@extendedsubset.com> Date: Tue, 01 Dec 2009 21:45:33 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> <4B15D9D2.3010107@stpeter.im> In-Reply-To: <4B15D9D2.3010107@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Todd Glassey , ietf-honest@lists.iadl.org, rms@gnu.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 List-Id: "This is the mailing list 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, 02 Dec 2009 03:45:47 -0000 Peter Saint-Andre wrote: > On 11/30/09 9:09 PM, Richard Stallman wrote: >> 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? > > Agreed, the term "intellectual property" is only bound to lead to > muddled thinking. Seems to me that, in the context of asking parties to self-declare their "IP", it's better to error on the side of overly broad terminology. You want to know what they think they've got more than what they actually have. Someone somewhere is thinking he has a trademark on the first four octets of a protocol message and it would be good to get that out on the table. But for discussions of any specific situation, or of the topic in general, you'd normally want to use the most precise term (unless you're attempting to hide the weaknesses of your argument underneath the muddle). - Marsh From marsh@extendedsubset.com Tue Dec 1 20:04: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 3534A28C136 for ; Tue, 1 Dec 2009 20:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFU16VHndvae for ; Tue, 1 Dec 2009 20:04:53 -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 7667528C11B for ; Tue, 1 Dec 2009 20:04: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 1NFgSK-00055g-DV; Wed, 02 Dec 2009 04:04:44 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 98DCF603C; Wed, 2 Dec 2009 04: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: U2FsdGVkX1/8j2xvIY0F8iasYQvxaWyLM3D/J7FJKvU= Message-ID: <4B15E759.7070108@extendedsubset.com> Date: Tue, 01 Dec 2009 22:04:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912020329.nB23TMcL010059@fs4113.wdf.sap.corp> In-Reply-To: <200912020329.nB23TMcL010059@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: ekr@rtfm.com, tls@ietf.org, Kyle Hamilton Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 04:04:54 -0000 Martin Rex wrote: > Kyle Hamilton wrote: >> 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. > > It has been previously mentioned: this is likely an insufficiently > clear wording of the spec. It sure sounds wrong that a implementation could become conformant with no discernible change on the wire. > The TLS_RENEGO_PROTECTION_REQUEST cipher suite value is _not_ > a means to request secure renegotiation (for the TLS extension RI, > only the extension containing the verify_data is such a request). > > The purpose of the magic cipher suite is a request for protection > from the _INsecure_ or "old" renegotiation. Good point. > The spec should explicitly say that every updated/conforming client > MUST add that cipher suite value into every ClientHello handshake > message that it sends out, and that includes clients that do not > implement renegotiation or have it disabled. It must add the MCSV and/or the extension. > That decision MUST > be free from policy and configuration. I understand the sentiment, but that wording doesn't make sense to me. To the extent that we're defining a wire protocol rather than certifying specific implementations, restrictions like that don't belong. After all, what stops them from adding a configuration switch to enable or disable support for the draft altogether? Seems like any arguments in support of that wording would also apply to every other usage of 'MUST' in every RFC. Which is a pretty good reason not to include it. - Marsh From Chris.Newman@Sun.COM Tue Dec 1 23: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 810843A69EE; Tue, 1 Dec 2009 23:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=0.150, 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 br9VkAx+c8qq; Tue, 1 Dec 2009 23:05:30 -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 4F1283A6844; Tue, 1 Dec 2009 23:05:30 -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 nB275Kgp028547; Tue, 1 Dec 2009 23:05:20 -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 <0KU000900JGP8W00@fe-sfbay-10.sun.com>; Tue, 01 Dec 2009 23:05:20 -0800 (PST) Received: from [192.168.15.4] ([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 <0KU000FGJJOUFB80@fe-sfbay-10.sun.com>; Tue, 01 Dec 2009 23:05:20 -0800 (PST) Date: Tue, 01 Dec 2009 23:04:43 -0800 From: Chris Newman In-reply-to: <20091130153734.D44C63A6AA9@core3.amsl.com> Sender: Chris.Newman@Sun.COM To: ietf@ietf.org Message-id: X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <20091130153734.D44C63A6AA9@core3.amsl.com> 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: Wed, 02 Dec 2009 07:05:31 -0000 I strongly support publishing this draft either in its present form or with any modification that does not impact the protocol's security analysis. This the most time-sensitive and security-critical IETF draft with respect to impact on the Internet community that I have seen in 17 years of IETF participation. As such, I strongly support the decision to start IETF last call early as permitted by RFC 2418 section 7.4. I also encourage the IESG to move this document to the front of the queue for all support organizations (Secretariat, IANA, RFC editor) when processing occurs and to avoid holding a blocking DISCUSS after the telechat unless that blocking issue is more serious than the ongoing presence of this TLS security vulnerability on the Internet. === Three changes to draft-ietf-tls-renegotiation-01 I consider important (but not blocking): * The header should explicitly state it Updates RFC 5246, 4346, 4366, 2246. This gets forward pointers in the RFC index to increase chances implementers of those specs will also find this one. This is also necessary for RFC 5246 as this creates an exception to a MUST NOT. * There is an error-of-fact in the introduction; this is incorrect: " If certificate-based client authentication is used, the server will believe that the initial traffic corresponds to the authenticated client identity." This statement is true only for application protocols with a badly designed state transition from unauthenticated to authenticated state. That is primarily limited to HTTPS and protocols based on HTTPS. It is not true for most other IETF application protocols including SMTP, POP, IMAP, LDAP, NNTP, BEEP and XMPP (however, I suspect all of these are impacted by the TLS vulnerability in other ways). Changing "is used" to "is used with HTTPS" would correct the error. * Nomenclature: when discussing TLS_RENEGO_PROTECTION_REQUEST, the term "cipher suite value" needs to be used instead of "cipher suite", and the text needs to explicitly state that TLS_RENEGO_PROTECTION_REQUEST is not a cipher suite (it is not sufficient to say it can't be negotiated). This is important for evaluating implementations against government standards that dictate which cipher suites an implementation may advertise. Evaluation relative to draft-mrex-tls-secure-renegotiation-03: Kudos to Martin Rex for producing such a good alternate proposal. The introductory text up to and including section 4.1 is very good and would improve draft-ietf-tls-renegotiation. While I would support a consensus to publish the mrex document as the solution, I presently prefer draft-ietf-tls-renegotiation-01 for four reasons: 1. Running code: multiple implementations and interop testing was performed on an earlier version of draft-ietf-tls-renegotiation. 2. Impact to core protocol handshake: The mrex proposal alters the handshake to include data that is not exchanged in-protocol. If this impacts PKCS#11 hardware tokens or other SSL accelerators (an issue mentioned by Dr Stephen Henson on the TLS list on Nov 26, 2009 19:24:55 +0000) that could severely impact deployment. I do not know if that concern applies to the mrex proposal, but I know it does not apply to the draft-ietf-tls-renegotiation. The point being the mrex proposal requires more analysis to verify impact. As we're in a hurry, I prefer to easier to analyze proposal. 3. Extensibility. In my experience one of the protocol design features most important to get right is extensibility. SSL/TLS didn't really get that right until v1.2 (which is causing problems now). As draft-ietf-tls-renegotiation uses the TLS extension facility more extensively, it will help future-proof more implementations. 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some circumstances. That approach is untested in the field and I have concerns it will negatively impact middleboxes. As draft-ietf-tls-renegotiation allows use of either the cipher suite value or the extension for C->S signaling, that mitigates the concern -- the field can choose the mechanism that works best. My take on some controversial issues: * There may not be a sufficient number of "extension intolerant" SSL/TLS servers in operation to justify the added complexity of TLS_RENEGO_PROTECTION_REQUEST. However, I do not object to inclusion as it's possibly helpful for some alleged extension intolerant servers compliant with early drafts of SSLv3 and it helped move closer to WG consensus. * I believe Bodo Moeller's proposal to exclude client's verify_data from ServerHello improves the protocol, but I do not find it a blocking or compelling issue. * I find the present text in security considerations on identity change mid-stream acceptable from my perspective as an application developer. However, I do not care if that text is included or excluded from the approved version as it is ancillary to the important core purpose. * Changing the handshake hash to include the previous verify_data after renegotiation: In the abstract, I find the "fail safe" nature of including verify_data in the hash a better design than having to explicitly check validity. However, I find that less compelling than issues 1 & 2 above. Particularly given that TLS already requires skilled implementers to get tricky details correct in a fashion that can not be easily verified (e.g. PRNG). * Non-extension signaling for ServerHello: I am strongly opposed to using any mechanism other than TLS extensions for signaling in the ServerHello. I found all such proposals (including overloading the version field) far too risky. As the earlier mrex draft proposing such mechanisms was replaced by a revision which now uses the extension mechanism, I believe the matter is settled. - Chris From peter.robinson@rsa.com Tue Dec 1 23:27: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 CF50F3A69EE; Tue, 1 Dec 2009 23:27:48 -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 GLujvBCxw5rq; Tue, 1 Dec 2009 23:27:47 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id D916A3A6A32; Tue, 1 Dec 2009 23:27:39 -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 nB27RVTH003695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 02:27:31 -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, 2 Dec 2009 02:27:24 -0500 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id nB27RNxI019984; Wed, 2 Dec 2009 02:27:24 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.51]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 02:27:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Dec 2009 02:27:21 -0500 Content-Type: multipart/signed; boundary="----=_NextPart_000_0994_01CA7374.B4BB8830"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard thread-index: Acpx0138KCsc0GUGQXikdtGWh19/SgBTPLQg References: <20091130153734.D44C63A6AA9@core3.amsl.com> From: To: , X-OriginalArrivalTime: 02 Dec 2009 07:27:23.0875 (UTC) FILETIME=[E43BC330:01CA7320] X-EMM-EM: Active 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: Wed, 02 Dec 2009 07:27:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0994_01CA7374.B4BB8830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >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 My colleagues and I support this draft. We would like the following to be considered: In section 1 there is a missing full stop: >thus be detected This Should be: >thus be detected. This In section 1, there is a reference to the extension prior to it being defined. Perhaps the following should be changed from: >An attempt by an attacker to inject himself as >described above will result in a mismatch of the extension and can >thus be detected To: >An attempt by an attacker to inject himself as >described above will result in a mismatch of the handshake hash and can >thus be detected In section 1, an ID is mentioned. I am not sure it adds anything to the specification having this here. Perhaps if the purpose is to acknowledge the people who created the draft, they could be acknowledged in the Acknowledgements section. Given this, I think that the following should be removed: >The extension described here is similar >to that used for TLS Channel Bindings >[I-D.altman-tls-channel-bindings]. If this were to be removed, the text in section 3 would also need to be removed: >Note that this value is the "tls-unique" >channel binding from [I-D.altman-tls-channel-bindings] In section 3 the term "TLS resumption" is used. In RFC5246 I think this is typically referred to as "session resumption". Perhaps the text should be changed from: >The above rules apply even when TLS resumption is used. To: >The above rules apply even when TLS session resumption is used. In section 4 there is a typo, a " is missing and the word "in" is missing. This line should be changed from: >"renegotiation_info" extension, only renegotiation_info" may be used >rehandshakes. To: >"renegotiation_info" extension, only "renegotiation_info" may be used >in rehandshakes. In section 4 last paragraph it discusses a minimal client. It says: >Any compliant server will reject any (apparent) attempt >at renegotiation by such a client. And in section 3 it says: >If the contents >are incorrect, then it MUST generate a fatal "handshake_failure" >alert and terminate the connection. This implies that the cipher suite is not entirely equivalent to an empty renegotiation_info extension. If a server receives an empty renegotiation_info extension on a rehandshake then it must generate a fatal "handshake_failure" alert and terminate the connection rather than merely rejecting the renegotiation (by generating a "no_renegotiation" alert at warning level). I think that the paragraph in section 4 should be altered to say: >Any compliant server MUST generate a fatal "handshake_failure" >alert and terminate the connection when it sees any (apparent) attempt >at renegotiation by such a client. In section 6.1, it says the word "rehandshakes" when I think that it should say "renegotiates". Hence, change from: >reject all rehandshakes and simply not signal it. However, it is not To: >reject all renegotiates and simply not signal it. However, it is not 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. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The IESG Sent: Tuesday, 1 December 2009 1: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=view_id&dTag=19412&rfc_flag=0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0994_01CA7374.B4BB8830 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 AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTIwMjA3MjcyMVowIwYJKoZIhvcNAQkE MRYEFOreHn2RHH0eNfNgsf2ZmUN6ZEImMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA bbRR6G1NXcXZ4FpMJ47ypTpF8MECGvATzvDEQrs7mrRgeX6TWIiYNqTaDMerqyxkLXp/e4VkzMt2 v0nvtBoYP7Ds2se8uhYckm8KYT6kxyLodToXCvMAbElim1D+kKTHAyL+HKZ8amrU9L07hePqlxhL U4YdY5fVt1ptViw46nAAAAAAAAA= ------=_NextPart_000_0994_01CA7374.B4BB8830-- From djhopwood@googlemail.com Tue Dec 1 23:47: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 061373A683D for ; Tue, 1 Dec 2009 23:47: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=[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 Io9Ewdv-7mZB for ; Tue, 1 Dec 2009 23:47:26 -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 E07B93A6A32 for ; Tue, 1 Dec 2009 23:47:20 -0800 (PST) Received: by ewy6 with SMTP id 6so747518ewy.29 for ; Tue, 01 Dec 2009 23:47: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=BSliFNqlU4yN8KCTdPTzBfoRkL3FhpOWKOcZ/GRuajw=; b=Bboqj2xWATp9RXJBqVAkuHZsiSjp8QzTUE0AyaiZMz3JcfJGeSKPvWebMUrWclzrSf HoHf0HhqULwzoqEJUJDP9xhegjNAzEEOiMD6IoLQDr1awr0iQa+7DYAHrcWd5bGyKf+u 106v/CHEu/nyEHbi75dfCpSBlJbZ93Zo9C59g= 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=GTUl4DeQQi/A7wqn4dnerqaUn6iu3WGjQrKEos8jGWFXGmWR+81PEZVh9Zj0KdEeIW x3lphiKkdOxIMZEoOQl39SRcyA7tdZ6eGgr/2xrZCGLMyDlIL1CBMGMZV64xG66yffEy KZRDuDks5G8OMaYoe1oLlW2VnoabwLnURrNIE= Received: by 10.213.2.70 with SMTP id 6mr7085613ebi.25.1259740029201; Tue, 01 Dec 2009 23:47:09 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 28sm1699945eyg.20.2009.12.01.23.47.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 23:47:08 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B161B6D.5090008@jacaranda.org> Date: Wed, 02 Dec 2009 07:46: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: <200912020249.nB22nvQ0007879@fs4113.wdf.sap.corp> In-Reply-To: <200912020249.nB22nvQ0007879@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC21DA9DABCE956E1BAF755AA" Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 07:47:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC21DA9DABCE956E1BAF755AA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > And btw. the document that standardizes the secure renegotiation > will have to say that it updates RFC-5246, because it needs to. And RFCs 2246, 4346, and 4366. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigC21DA9DABCE956E1BAF755AA 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/ iF4EAREIAAYFAksWG3QACgkQWUc8YzyzqAfnUQEAkBO7LAYIRIyL5zF4w5LwVDwm SDEG4ocOIQalI+5jVz4A/j1BEhZ2hp/J6CkfypnqZXMY0ASRXp0fx6QZlY895aHW =OIO+ -----END PGP SIGNATURE----- --------------enigC21DA9DABCE956E1BAF755AA-- From ynir@checkpoint.com Wed Dec 2 01:12: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 2ADF83A6A80; Wed, 2 Dec 2009 01:12:51 -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 CPMNHvL7mCSI; Wed, 2 Dec 2009 01:12:50 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0E1343A69A2; Wed, 2 Dec 2009 01:12:39 -0800 (PST) X-CheckPoint: {4B162F48-10006-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2746B29C004; Wed, 2 Dec 2009 11:12:30 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0B76629C002; Wed, 2 Dec 2009 11:12:30 +0200 (IST) X-CheckPoint: {4B162F48-10002-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 nB29CTGo019007; Wed, 2 Dec 2009 11:12: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; Wed, 2 Dec 2009 11:12:36 +0200 From: Yoav Nir To: Chris Newman Date: Wed, 2 Dec 2009 11:12:26 +0200 Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: AcpzL5ZNQnpDwYyzSfKAmmCTNlbBYA== 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: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "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: Wed, 02 Dec 2009 09:12:51 -0000 On Dec 2, 2009, at 9:04 AM, Chris Newman wrote: >=20 > This the most time-sensitive and security-critical IETF draft with respec= t=20 > to impact on the Internet community that I have seen in 17 years of IETF= =20 > participation. =20 This is the part I disagree with. New extensions to protocols will take years to deploy. There's no getting a= round this. SSL/TLS servers that do not depend on renegotiation can disable renegotiati= ons entirely. They can do this NOW. SSL/TLS servers that rely on renegotiation only for the upgrade-to-mutual f= eature for web servers can disable client-initiated renegotiations, and twe= ak their web applications so that the prefix injection doesn't matter. The = can do this NOW. (We did) The only real case of using renegotiation that I've heard about was identit= y protection, where the client connects anonymously first, and then present= s the certificate during the (encrypted) renegotiation. This is probably ve= ry rare, and accounts for a fraction or a percent of SSL use. So I don't think we should sit on our thumbs or even wait until the next fa= ce-to-face meeting, but whatever the RFC says, it will take years to deploy= on the general Internet. We should hurry, but we shouldn't rush into thing= s. From Pasi.Eronen@nokia.com Wed Dec 2 05:33: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 6D6E33A698D for ; Wed, 2 Dec 2009 05:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 ZUvhiRk2SA9i for ; Wed, 2 Dec 2009 05:33:40 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4CB193A688D for ; Wed, 2 Dec 2009 05:33:39 -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 nB2DWtXm021078; Wed, 2 Dec 2009 15:33:26 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 15:33:07 +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); Wed, 2 Dec 2009 15:33:07 +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, 2 Dec 2009 14:33:05 +0100 From: To: Date: Wed, 2 Dec 2009 14:33:02 +0100 Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: AcpyAgDrC/vbU7fKSHetJ5R8xB9ZHgBUZ5TQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F311EB737@NOK-EUMSG-01.mgdnok.nokia.com> 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: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Dec 2009 13:33:07.0441 (UTC) FILETIME=[FB9E3610:01CA7353] X-Nokia-AV: Clean 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: Wed, 02 Dec 2009 13:33:41 -0000 Bodo Moeller wrote: > 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. Note that this text is qualified by "except if the application asks for it" -- so applications that need this flexibility can have it. (But somehow quite many people have missed this, so it's clear the text isn't sufficiently clear as-is...) Best regards, Pasi From mrex@sap.com Wed Dec 2 06:20: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 1239E3A688A; Wed, 2 Dec 2009 06:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 5k73q29exLMg; Wed, 2 Dec 2009 06:20:06 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 360013A63EC; Wed, 2 Dec 2009 06:20:05 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB2EJu65003099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 15:19:56 +0100 (MET) From: Martin Rex Message-Id: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> To: Chris.Newman@Sun.COM (Chris Newman) Date: Wed, 2 Dec 2009 15:19:53 +0100 (MET) In-Reply-To: from "Chris Newman" at Dec 1, 9 11:04: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: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 02 Dec 2009 14:20:08 -0000 Chris Newman wrote: > > Evaluation relative to draft-mrex-tls-secure-renegotiation-03: > > Kudos to Martin Rex for producing such a good alternate proposal. The > introductory text up to and including section 4.1 is very good and would > improve draft-ietf-tls-renegotiation. While I would support a consensus to > publish the mrex document as the solution, I presently prefer > draft-ietf-tls-renegotiation-01 for four reasons: > > 1. Running code: multiple implementations and interop testing was > performed on an earlier version of draft-ietf-tls-renegotiation. Even EKR admitted that implementing the update is an insignificant amount of work. Pushing this point, that there were interoperable implementations when this proposal was made in the IETF smells very much like a request for rubber stamping. > 2. Impact to core protocol handshake: The mrex proposal alters the > handshake to include data that is not exchanged in-protocol. > If this impacts PKCS#11 hardware tokens or other SSL accelerators > (an issue mentioned by Dr Stephen Henson on the TLS list on > that could severely impact deployment. Crypto hardware in general and PKCS#11 are not affected. What I am changing is the plaintext input to a hash or hash-like function. What might be affected is hardware implementations of SSL/TLS or hardware-support for SSL/TLS in TLS endpoints. It might be a firmware rather than hardware issue there. So far, I haven't seen any vendor/implementor that is facing such difficulties raising such concerns. Which could mean two things: 1. there is no problem 2. those vendors/implementors have not looked at / evaluated the current proposals. (1) would make it a non-issue and (2) would indicate than a decision in the IETF is _premature_, we would have to ask some of those vendors/implementers for feedback before making a decision. > > 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some > circumstances. That approach is untested in the field and I have > concerns it will negatively impact middleboxes. Huh? That sounds extremely unbelievable. Do any of the browser vendors cut down on ciphersuites in their current reconnect fallbacks -- and remove ciphersuites like those with AES? A quick glance indicates that Firefox 3.0.15 happily sends a list of 18 ciphersuites, including Camellia, in an SSLv2 ClientHello on reconnect fallback. > > As draft-ietf-tls-renegotiation allows use of either the cipher suite > value or the extension for C->S signaling, that mitigates the concern -- > the field can choose the mechanism that works best. I consider this a defect in draft-ietf-tls-renegotiation-01. There should be exactly **ONE** signaling mechanism for the initial ClientHello on a connection so that extensions-tolerant but extensions-free Servers will not be force to wade through lists of extensions sent by clients. The existing fallbacks or conservative approaches give you a hint where you may expect interop problems. TLS extensions are a known interop problem. > > My take on some controversial issues: > > * There may not be a sufficient number of "extension intolerant" SSL/TLS > servers in operation to justify the added complexity of > TLS_RENEGO_PROTECTION_REQUEST. However, I do not object to inclusion as > it's possibly helpful for some alleged extension intolerant servers > compliant with early drafts of SSLv3 and it helped move closer to WG > consensus. That cipher suite value is definitely not added complexity. On the contrary, it is significantly reduced complexity. We are not discussing about a new optional feature here, but instead about something that should be patched into as many old clients and servers as possible. And a number of clients MUST remain interoperable with servers that will _not_ be patched. Therefore requiring anything that will break interop in the productive installed base is completely inacceptable when it can be avoided (which it easily can be). -Martin From Chris.Newman@Sun.COM Wed Dec 2 08:12: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 B5F723A67E2; Wed, 2 Dec 2009 08:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.946 X-Spam-Level: X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=0.100, 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 xIvtfp0KeEJQ; Wed, 2 Dec 2009 08:12:18 -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 465D53A66B4; Wed, 2 Dec 2009 08:12:18 -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 nB2GCASa020257; Wed, 2 Dec 2009 08:12:10 -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 <0KU100H008OCOL00@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 08:12:10 -0800 (PST) Received: from [192.168.15.4] ([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 <0KU1007BA8ZZ7Y40@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 08:12:02 -0800 (PST) Date: Wed, 02 Dec 2009 08:11:55 -0800 From: Chris Newman In-reply-to: Sender: Chris.Newman@Sun.COM To: Yoav Nir Message-id: <842A594AA7B5E5FCF400CFE5@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <20091130153734.D44C63A6AA9@core3.amsl.com> Cc: ietf@ietf.org, 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: Wed, 02 Dec 2009 16:12:20 -0000 --On December 2, 2009 11:12:26 +0200 Yoav Nir wrote: > On Dec 2, 2009, at 9:04 AM, Chris Newman wrote: >> >> This the most time-sensitive and security-critical IETF draft with >> respect to impact on the Internet community that I have seen in 17 >> years of IETF participation. > > This is the part I disagree with. Since that's a statement about my observations, you'd have to propose a different draft that better met that criteria in the last 17 years and get me to agree ;-) > New extensions to protocols will take years to deploy. There's no getting > around this. > > SSL/TLS servers that do not depend on renegotiation can disable > renegotiations entirely. They can do this NOW. SSL/TLS servers that rely > on renegotiation only for the upgrade-to-mutual feature for web servers > can disable client-initiated renegotiations, and tweak their web > applications so that the prefix injection doesn't matter. The can do this > NOW. (We did) > > The only real case of using renegotiation that I've heard about was > identity protection, where the client connects anonymously first, and > then presents the certificate during the (encrypted) renegotiation. This > is probably very rare, and accounts for a fraction or a percent of SSL > use. > > So I don't think we should sit on our thumbs or even wait until the next > face-to-face meeting, but whatever the RFC says, it will take years to > deploy on the general Internet. We should hurry, but we shouldn't rush > into things. The problem is more a customer-service one than a purely technical one: there's a real problem with just turning off SSL/TLS renegotiation by default. Yes, it's what vendors are working on doing, but it's just an interim solution. Basically, a vendor has to go to an HTTP server customer and say: You need to patch your HTTP server to stop a security vulnerability , but it might break your server deployment if , you can work around that problem if you do or . It doesn't matter if the downside only impacts 1% of the HTTP server customers as the analysis of whether they'll be impacted may take time and money and that 1% may be the people who most urgently need the vulnerability fixed. When the vulnerability in the IETF specification is fixed and has made it to 2-3 major browser vendors, the message to HTTP server customers becomes more reasonable (albeit still unsatisfactory). While the is feasible for a vendor with a small HTTP footprint and solid tech knowledge like yourself, it's less feasible for large corporate sites that would have to analyze thousands of HTTP-based services. - Chris From benl@google.com Wed Dec 2 08:32: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 555CA3A686C for ; Wed, 2 Dec 2009 08:32:03 -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 A7-8fj-gQMG7 for ; Wed, 2 Dec 2009 08:32:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 15CCB3A6839 for ; Wed, 2 Dec 2009 08:32:01 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nB2GVqmJ031192 for ; Wed, 2 Dec 2009 16:31:53 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259771513; bh=pV4ZS4uezdW+Net6VIWpQGpFqWk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=K0Z+uRzfPGjXY11M3Kd5m3r/0lYmUo9QKqESjzKVW7azPhj22EN+ZAFY1iWygaapB 2MVCOzfihTOutyXyn/SUw== 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=DYltDyq07BTgAYTkOsB1nYptxT9ORX97t+Vo3pgIgGlYVMMfAV2e1SEV1Ftm/nxCx Iox20nNT8xaPvk6NCfcIw== Received: from yxe27 (yxe27.prod.google.com [10.190.2.27]) by wpaz17.hot.corp.google.com with ESMTP id nB2GVnn2021817 for ; Wed, 2 Dec 2009 08:31:50 -0800 Received: by yxe27 with SMTP id 27so308404yxe.10 for ; Wed, 02 Dec 2009 08:31:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.151.89.32 with SMTP id r32mr636132ybl.289.1259771508220; Wed, 02 Dec 2009 08:31:48 -0800 (PST) In-Reply-To: <4B1592F5.2050706@extendedsubset.com> References: <200912010205.nB125SkT006982@fs4113.wdf.sap.corp> <4B153247.1030402@extendedsubset.com> <20091201185104.GG773@Sun.COM> <4B157559.3050405@extendedsubset.com> <20091201212642.GM773@Sun.COM> <4B1592F5.2050706@extendedsubset.com> Date: Wed, 2 Dec 2009 08:31:48 -0800 Message-ID: <1b587cab0912020831oc76821bk8f689cd25ad840a2@mail.gmail.com> From: Ben Laurie To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls@ietf.org, Nicolas Williams 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: Wed, 02 Dec 2009 16:32:03 -0000 On Tue, Dec 1, 2009 at 2:04 PM, Marsh Ray wrote: > Nicolas Williams wrote: >> On Tue, Dec 01, 2009 at 01:58:17PM -0600, Marsh Ray wrote: >>> Or you could just use memcmp(). >> >> No, that's a problem: implementors might forget and still interop. =A0An > > Again, they could also forget to check Finished.verify_data and many > other conditions. No one wanted to add another thing to get right just > for the fun of it, but at the end of the day draft-ietf-tls-renego is a > relatively simple fix for a pretty deep problem. =A0Personally, I think w= e > should be grateful to get off so easy. > >> implementor that forgets to insert the channel binding data where it >> belongs will simply fail to interop, thus they will not forget. > > The existence of publicly-available exploit code will help them to not > forget. Someone posted some to the full-disclosure list in early November= . > > Developers can just modify a byte in the debugger and watch the remote > behavior. QA testers (and other interested parties) could benefit from a > tool. > > I've refused all requests for my exploit code, but it seems like we > could come up with a test client or server that merely simulated an > incoming exploit by handling a renegotiation with an empty or incorrect > extension data. This would give product testers something to work with. Exactly. I'm stunned that there's been so much discussion over something that can be tested for so easily. On the other hand, I have to admit that OpenSSL does not seem to test renegotiation at all, which ought to get fixed! > > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Chris.Newman@Sun.COM Wed Dec 2 09: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 B08463A6AD8; Wed, 2 Dec 2009 09:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.075, 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 u5w9mfC8v8dU; Wed, 2 Dec 2009 09:09:35 -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 C24B03A6ABC; Wed, 2 Dec 2009 09:09:35 -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 nB2H9RDh025919; Wed, 2 Dec 2009 09:09:27 -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 <0KU100C00ANHI200@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 09:09:27 -0800 (PST) Received: from [192.168.15.4] ([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 <0KU10084HBNKTC20@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 09:09:23 -0800 (PST) Date: Wed, 02 Dec 2009 09:08:45 -0800 From: Chris Newman In-reply-to: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> Sender: Chris.Newman@Sun.COM To: mrex@sap.com Message-id: <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 17:09:36 -0000 --On December 2, 2009 15:19:53 +0100 Martin Rex wrote: >> 1. Running code: multiple implementations and interop testing was >> performed on an earlier version of draft-ietf-tls-renegotiation. > > Even EKR admitted that implementing the update is an insignificant > amount of work. > > Pushing this point, that there were interoperable implementations > when this proposal was made in the IETF smells very much like > a request for rubber stamping. The IETF's motto is "rough consensus and running code". So "running code" matters. "rubber stamping" is only a problem if incompatible changes are refused, but the fact such changes were made makes that straw man moot. >> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in >> some circumstances. That approach is untested in the field and I have >> concerns it will negatively impact middleboxes. > > Huh? That sounds extremely unbelievable. First, I'll reiterate that I found both proposals acceptable, so the four points I made were all matters of design preference for this situation and not issues I find strongly compelling. The issue with middleboxes was raised by others and is a straw man. There are government standards that have a fixed list of cipher suites and most clients can be configured to comply with those standards today. Given the TLS standards available at the time, a middlebox which enforced the presence of just those cipher suites and no others in the TLS handshake would reasonably be expected to be forwards compatible. Use of a mandatory-to-implement cipher suite value will require such middleboxes to be upgraded, thus slowing deploying. I'm not a fan of middleboxes, but we shouldn't break them gratuitously. >> As draft-ietf-tls-renegotiation allows use of either the cipher suite >> value or the extension for C->S signaling, that mitigates the concern >> -- the field can choose the mechanism that works best. > > I consider this a defect in draft-ietf-tls-renegotiation-01. > There should be exactly **ONE** signaling mechanism for the initial > ClientHello on a connection so that extensions-tolerant but > extensions-free Servers will not be force to wade through lists > of extensions sent by clients. I'd be fine with one signaling mechanism as long as it's the mechanism that's been standardized since 2006 and backwards-compatible with correct implementations since 1999 (TLS 1.0). If we're misusing a cipher suite value as a protocol extensibility flag, an issue I'm willing to compromise on despite the lack of strong evidence it's necessary, we unfortunately need two signaling mechanisms: one that's standard that we know will work with modern correct implementations, and one a kludge that works with very old software, but might break good-faith modern implementations (like the middlebox straw man above). > The existing fallbacks or conservative approaches give you a hint > where you may expect interop problems. TLS extensions are a known > interop problem. While I've seen evidence of bugs in TLS extension handling, and backwards compatibility fallback code that's been present in browsers since 1999, I've seen no evidence that extensions are an interoperability problem for correct standards-compliant TLS implementations or that such fallback code is necessary in operation today. - Chris From marsh@extendedsubset.com Wed Dec 2 09: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 B22403A6953; Wed, 2 Dec 2009 09:20:04 -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 YFd-O3gEBAtI; Wed, 2 Dec 2009 09:20:03 -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 4728C3A67A5; Wed, 2 Dec 2009 09:20:02 -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 1NFsro-000H2q-Tx; Wed, 02 Dec 2009 17:19:54 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 74902603C; Wed, 2 Dec 2009 17:19: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: U2FsdGVkX193hkCVm4d8lP65PmLBtAdapBS0vRpWw/U= Message-ID: <4B16A1B4.2050400@extendedsubset.com> Date: Wed, 02 Dec 2009 11:19:48 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> In-Reply-To: <200912021419.nB2EJr13019589@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: Chris Newman , ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 17:20:04 -0000 Martin Rex wrote: > Chris Newman wrote: >> Evaluation relative to draft-mrex-tls-secure-renegotiation-03: >> >> Kudos to Martin Rex for producing such a good alternate proposal. The >> introductory text up to and including section 4.1 is very good and would >> improve draft-ietf-tls-renegotiation. While I would support a consensus to >> publish the mrex document as the solution, I presently prefer >> draft-ietf-tls-renegotiation-01 for four reasons: >> >> 1. Running code: multiple implementations and interop testing was >> performed on an earlier version of draft-ietf-tls-renegotiation. > > Even EKR admitted that implementing the update is an insignificant > amount of work. > > Pushing this point, that there were interoperable implementations > when this proposal was made in the IETF smells very much like > a request for rubber stamping. My goal had been to present a usable solution along with the disclosure of the vulnerability. When it comes to closing exploitable security holes, a usable solution today is better than a perfect solution next year. If that's rubber stamping to you, well sorry. >> 2. Impact to core protocol handshake: The mrex proposal alters the >> handshake to include data that is not exchanged in-protocol. >> If this impacts PKCS#11 hardware tokens or other SSL accelerators >> (an issue mentioned by Dr Stephen Henson on the TLS list on >> that could severely impact deployment. > > Crypto hardware in general and PKCS#11 are not affected. What I am > changing is the plaintext input to a hash or hash-like function. Agree. > What might be affected is hardware implementations of SSL/TLS > or hardware-support for SSL/TLS in TLS endpoints. It might be > a firmware rather than hardware issue there. > > So far, I haven't seen any vendor/implementor that is facing such > difficulties raising such concerns. > > Which could mean two things: > 1. there is no problem > 2. those vendors/implementors have not looked at / evaluated > the current proposals. > > (1) would make it a non-issue and (2) would indicate than a decision > in the IETF is _premature_, we would have to ask some of those > vendors/implementers for feedback before making a decision. I am a bit disappointed that we have not had better participation from the vendors, particularly hardware. My suspicion is that they're reticent to discuss what they're up against either publicly or privately. We can't delay the solution for the large percentage of affected deployments that are represented by vendors who did choose to participate in the discussion for the sake of those who did not. >> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some >> circumstances. That approach is untested in the field and I have >> concerns it will negatively impact middleboxes. > > Huh? That sounds extremely unbelievable. I suspect that some inspecting firewall or IDS box somewhere is going to take issue with the new cipher suite value and have to be reconfigured. I also believe that it's a minimal concern and it's the least-breaking of all the possible signaling methods. > Do any of the browser vendors cut down on ciphersuites in their > current reconnect fallbacks -- and remove ciphersuites like > those with AES? > > A quick glance indicates that Firefox 3.0.15 happily sends > a list of 18 ciphersuites, including Camellia, in an SSLv2 ClientHello > on reconnect fallback. My experiments were showing that some clients would advertise a reduced list of cipher suites in the renegotiation hello. >> As draft-ietf-tls-renegotiation allows use of either the cipher suite >> value or the extension for C->S signaling, that mitigates the concern -- >> the field can choose the mechanism that works best. > > I consider this a defect in draft-ietf-tls-renegotiation-01. > There should be exactly **ONE** signaling mechanism for the initial > ClientHello on a connection so that extensions-tolerant but > extensions-free Servers will not be force to wade through lists > of extensions sent by clients. It's a three-to-five line 'for' loop. > The existing fallbacks or conservative approaches give you a hint > where you may expect interop problems. TLS extensions are a known > interop problem. Those servers need to be patched or you wouldn't want to trust connecting to them anyway. Client implementations can use the MCSV (magic cipher suite value) on the initial hello if they prefer. >> My take on some controversial issues: >> >> * There may not be a sufficient number of "extension intolerant" SSL/TLS >> servers in operation to justify the added complexity of >> TLS_RENEGO_PROTECTION_REQUEST. However, I do not object to inclusion as >> it's possibly helpful for some alleged extension intolerant servers >> compliant with early drafts of SSLv3 and it helped move closer to WG >> consensus. > > That cipher suite value is definitely not added complexity. > On the contrary, it is significantly reduced complexity. Well, there are now three ways to signal in an initial client hello. The extension, the MCSV, or both. Some implementations will find the MCSV simpler, some the extension. > We are not discussing about a new optional feature here, but instead > about something that should be patched into as many old clients and > servers as possible. And a number of clients MUST remain interoperable > with servers that will _not_ be patched. Therefore requiring anything > that will break interop in the productive installed base is completely > inacceptable when it can be avoided (which it easily can be). +1 - Marsh From noskov@microsoft.com Wed Dec 2 09:27: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 EECE23A680F for ; Wed, 2 Dec 2009 09:27:41 -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 RvM9Fmy0bYMV for ; Wed, 2 Dec 2009 09:27:41 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 3A1B43A67D8 for ; Wed, 2 Dec 2009 09:27:41 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 09:28:00 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 2 Dec 2009 09:27:32 -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, 2 Dec 2009 09:27:15 -0800 From: Nasko Oskov To: "Pasi.Eronen@nokia.com" , "bmoeller@acm.org" Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: AQHKc1QbHPl5LdmAmUOriARUsw795JFSAk4w Date: Wed, 2 Dec 2009 17:26:44 +0000 Deferred-Delivery: Wed, 2 Dec 2009 17:27:00 +0000 Message-ID: References: <20091130153734.D44C63A6AA9@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB774F311EB737@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F311EB737@NOK-EUMSG-01.mgdnok.nokia.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] 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: Wed, 02 Dec 2009 17:27:42 -0000 Pasi Eronen wrote: >Bodo Moeller wrote: > > >> Keeping this language in the specification would have the weird=20 >> implication that applications that *need* the flexibility provided by=20 >> the TLS protocol (e.g., to allow renegotiation handshakes to switch to=20 >> a different ciphersuite, which may require a different certificate)=20 >> would have to to *skip* implementing the protocol update, and thus=20 >> stay vulnerable. > >Note that this text is qualified by "except if the application asks for it= " >-- so applications that need this flexibility can have it. >(But somehow quite many people have missed this, so it's clear the text >isn't sufficiently clear as-is...) I think it was clear enough, but I still believe we should not be changing such behavior as part of fixing the MiTM problem. A malicious endpoint of either end is not something we are trying to solve. Changing default behavior for apps will have potential to break things that we are not aware of. Asking each app to change to account for this new behavior is only going to make deploying this fix slower. I have heard of applications that rely on very short certificate lifetimes, so a long lived TLS session with certificate renewal at some point will cause breakage, while it will work just fine in today's world.=20 Binary comparisons of certificates is not an adequate comparison of identit= y and TLS relies on the application to do the right thing when it comes to identity. If we must keep this part, why not change it to a SHOULD to allo= w vendors the flexibility of choosing which way to go? Leaving it a MUST crea= tes a problem for implementers that do want to implement the draft but want to minimize breaking changes to the protocol. Thanks, Nasko From marsh@extendedsubset.com Wed Dec 2 09:41: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 C859F3A6807 for ; Wed, 2 Dec 2009 09:41:47 -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 rMe0SqB9TcTT for ; Wed, 2 Dec 2009 09:41: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 27E443A67F3 for ; Wed, 2 Dec 2009 09:41: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 1NFtCs-000OAZ-Ul; Wed, 02 Dec 2009 17:41:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4C046603C; Wed, 2 Dec 2009 17:41:37 +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/k+7pW6++2WFYL8O5jRZ7gmcboMxxbihQ= Message-ID: <4B16A6CF.2020002@extendedsubset.com> Date: Wed, 02 Dec 2009 11:41:35 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nasko Oskov References: <20091130153734.D44C63A6AA9@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB774F311EB737@NOK-EUMSG-01.mgdnok.nokia.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] 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: Wed, 02 Dec 2009 17:41:47 -0000 Nasko Oskov wrote: > > I think it was clear enough, but I still believe we should not be changing > such behavior as part of fixing the MiTM problem. A malicious endpoint of > either end is not something we are trying to solve. It also represents the first toe into the water of the TLS spec dictating the library<->app interface. Which is a whole nother discussion I think we would be wise not to bundle into this bug fix, as interesting as it will be. - Marsh From mrex@sap.com Wed Dec 2 10: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 E8D413A68AB; Wed, 2 Dec 2009 10:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 NHE62mk5aXQX; Wed, 2 Dec 2009 10:36: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 94B803A6A35; Wed, 2 Dec 2009 10:36:00 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB2IZpWi003687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 19:35:51 +0100 (MET) From: Martin Rex Message-Id: <200912021835.nB2IZo5m005224@fs4113.wdf.sap.corp> To: Chris.Newman@Sun.COM (Chris Newman) Date: Wed, 2 Dec 2009 19:35:50 +0100 (MET) In-Reply-To: <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> from "Chris Newman" at Dec 2, 9 09:08: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: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 02 Dec 2009 18:36:03 -0000 Chris Newman wrote: > > --On December 2, 2009 15:19:53 +0100 Martin Rex wrote: > >> 1. Running code: multiple implementations and interop testing was > >> performed on an earlier version of draft-ietf-tls-renegotiation. > > > > Even EKR admitted that implementing the update is an insignificant > > amount of work. > > > > Pushing this point, that there were interoperable implementations > > when this proposal was made in the IETF smells very much like > > a request for rubber stamping. > > The IETF's motto is "rough consensus and running code". So "running code" > matters. > "rubber stamping" is only a problem if incompatible changes are refused, > but the fact such changes were made makes that straw man moot. I remember the IETF discussions when S/MIME was brought to the IETF. "Running code" for new implementations is _NOT_ an issue for the decision we're doing here, since we agreed that the implementation effort for either proposal is insignificant. "Running code" as the installed base that draft-ietf-tls-renegotiation-01 might impair is _what_really_counts_. The software logistics around shipping a hotfix for a huge and in some instances very old installed base is the running code that needs to be relevant for the IETF decision. > > >> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in > >> some circumstances. That approach is untested in the field and I have > >> concerns it will negatively impact middleboxes. > > > > Huh? That sounds extremely unbelievable. > > First, I'll reiterate that I found both proposals acceptable, so the four > points I made were all matters of design preference for this situation and > not issues I find strongly compelling. You asked me directly to write up my proposal in an I-D on Nov 16th: http://www.ietf.org/mail-archive/web/tls/current/msg04400.html I agreed to writing an I-D here: http://www.ietf.org/mail-archive/web/tls/current/msg04410.html The WG-Chairs summary for EKRs draft on Nov 18th: http://www.ietf.org/mail-archive/web/tls/current/msg04464.html WG-Chairs consensus call for EKRs draft on Nov 20th (Friday) http://www.ietf.org/mail-archive/web/tls/current/msg04571.html to which I replied that I will post my new I-D on Monday Nov. 23rd (which I did), followed by a cleanup submission on Wed, Nov 25th. Considering that EKR had been involved in Project Mogul a few weeks before I realized the MITM-suceptibility of the TLS renegotiation and posted about it to tls@ietf.org, that he has been previously authoring and co-authoring documents around TLS, I think it's unfair to complain that my proposal is "late". It's my first I-D and and I'm not a TLS implementer myself (only responsible for maintenance, support and updates of the OEM SSL/TLS implementation that my company is shipping). > > The issue with middleboxes was raised by others and is a straw man. There > are government standards that have a fixed list of cipher suites and most > clients can be configured to comply with those standards today. You mean stuff like this here: http://iase.disa.mil/stigs/stig/index.html If you look at this governmental spec in particular (page 50): http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf then you should realize two things: - it requires support for SSLv2, which is mutually exclusive with a TLS extension (but fine with my proposal) - it refers to the configuration of cipher suites, and _NOT_ to the presence of ciphersuite IDs in ClientHello. - the explicit list in that document is to illustrate which of the _weak_ ciphersuites are not allowed, the underlying security requirement is strong encryption (128-bit). Middleboxes aborting on the cipher suite selection on the server is _much_ easier to implement and perfectly reliable. Changes to filtering middle boxes (like intrusion detection systems) is a moot point, because these are constantly updated anyway (which is quite different from several of the SSLv2 Servers that are still used in some places). No one would be using AntiVirus-Software with signatures that are several months or even several years old. > > Given the TLS standards available at the time, a middlebox which enforced > the presence of just those cipher suites and no others in the TLS handshake > would reasonably be expected to be forwards compatible. Use of a > mandatory-to-implement cipher suite value will require such middleboxes to > be upgraded, thus slowing deploying. I'm not a fan of middleboxes, but we > shouldn't break them gratuitously. If you look at the unix-stig-v5r1 standard, it does _not_ list AES ciphersuites (RFC-3268, June 2002). One would expect that those middle-boxes, if they care about the cipher_suites in the _list_ of the ClientHello rather than the negotiated cipher suite in ServerHello, should check the fixed short list of known-to-be-weak cipher suites listed in the above document rather than get in the way of future development (the latter does not seem to be the intention of that spec). > > >> As draft-ietf-tls-renegotiation allows use of either the cipher suite > >> value or the extension for C->S signaling, that mitigates the concern > >> -- the field can choose the mechanism that works best. > > > > I consider this a defect in draft-ietf-tls-renegotiation-01. > > There should be exactly **ONE** signaling mechanism for the initial > > ClientHello on a connection so that extensions-tolerant but > > extensions-free Servers will not be force to wade through lists > > of extensions sent by clients. > > I'd be fine with one signaling mechanism as long as it's the mechanism > that's been standardized since 2006 and backwards-compatible with correct > implementations since 1999 (TLS 1.0). TLS extensions is _not_ a signaling mechanism, and the "backwards-compatibility" amounts to "should be safely ignored when present, but we never actually tested that". It has been an optional and generic extension mechanism which the IETF never cared to make attractive until November 2009. Suddenly some folks want to make a hardly used optional feature a mandatory-to-implement functionality for all SSLv3 and TLS protocol versions back to 1994. (oh no, wait -- until ~nov 17th they were determined to simply kill all interop with SSLv3 and extensions-intolerant implentations of TLSv1.0). The original SSLv3 spec from Netscape did _not_ have the forward compatibility in ClientHello necessary for the installed base to not choke on the presence of TLS extension. Only the updated I-D document for SSLv3 that was produced in the IETF TLS working group (18-Nov-1996) had such a forward compatibility provision, however the TLS WG did _not_ care to publish that document as an informational RFC back then (so it was expired from the I-D repository 6 month after publication). And Netscape continued to provide the pretty PostScript & HTML spec of their SSLv3 spec without extensibility _much_ more prominently than the abandoned SSLv3 draft from the IETF TLS WG. TLS extensions (rfc-3546, June 2003) was a hardly-used option that came several years after TLSv1.0 (rfc-2246, Jan 1999) and was still a pure option in TLSv1.1 (rfc4346, April 2006) and not part of the TLSv1.1 base spec. > If we're misusing a cipher suite > value as a protocol extensibility flag, an issue I'm willing to compromise > on despite the lack of strong evidence it's necessary, we unfortunately > need two signaling mechanisms: one that's standard that we know will work > with modern correct implementations, and one a kludge that works with very > old software, but might break good-faith modern implementations (like the > middlebox straw man above). I'm sorry to disagree, but if a "modern correct implementation" has a problem with a signaling mechanism based on a cipher suite value in the ClientHello.cipher_suites list, then this implementation is neither modern nor correct! > > > The existing fallbacks or conservative approaches give you a hint > > where you may expect interop problems. TLS extensions are a known > > interop problem. > > While I've seen evidence of bugs in TLS extension handling, and backwards > compatibility fallback code that's been present in browsers since 1999, > I've seen no evidence that extensions are an interoperability problem for > correct standards-compliant TLS implementations or that such fallback code > is necessary in operation today. The IETF is fully aware that - the TLS rengotiation problem affects all protocol version of TLS including SSLv3 and in exactly the same fashion - it is extremely important that as many of the installed base is patched so that the number of servers and clients that need to tolerate and provide backwards interoperability with unpatched TLS peers can be reduced to a minimum. It is completely irrelevant how nicely this update fits with the most recents TLS implementations from the fancy new features department. What is extremely important is the interoperability with the RUNNING CODE out there maintained by the poor souls from the dirty old cruft department -- and how much hazzle it means for them to adopt this update. And it is much more about risk management for backwards-incompatible changes of a protocol and software in a potentially disruptive fashion for a productive installed base than it is about testing new features in a limited amount of new test installations where interop issues can be addressed and fixed with no time pressure whatsoever. -Martin From fluffy@cisco.com Wed Dec 2 11:18: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 912C53A6AC8; Wed, 2 Dec 2009 11:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 7KU-wv2G8qjV; Wed, 2 Dec 2009 11:18:37 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 77BBF3A6ABC; Wed, 2 Dec 2009 11:18:37 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADdMFkurRN+K/2dsb2JhbAC/eJd4hDEE X-IronPort-AV: E=Sophos;i="4.47,330,1257120000"; d="scan'208";a="71643160" Received: from sj-core-4.cisco.com ([171.68.223.138]) by rtp-iport-2.cisco.com with ESMTP; 02 Dec 2009 19:18:12 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB2JIBMs016327; Wed, 2 Dec 2009 19:18:11 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B14FFC0.3040404@cs.tcd.ie> Date: Wed, 2 Dec 2009 12:18:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8D3C5F3E-1416-4EC7-BD1C-CF3FED324126@cisco.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> <7C44D6AC-C936-4AAB-983C-A6928FE01637@checkpoint.com> <4B14FFC0.3040404@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1077) Cc: "ietf@ietf.org" , "tls@ietf.org 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: Wed, 02 Dec 2009 19:18:38 -0000 On Dec 1, 2009, at 4:36 AM, Stephen Farrell wrote: >> On Nov 30, 2009, at 5:37 PM, The IESG wrote: >>=20 >>> 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 I've been following this draft since early Oct and support publishing = it. I realize there are many things we could do and an infinite amount = of time could be spend examine. I believe that lots of people have = thought about the problem and solutions space and this draft represents = a good compromise on acting soon vs analyzing the solutions space = forever.=20 Cullen From mrex@sap.com Wed Dec 2 11: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 CDF4A28C0DB; Wed, 2 Dec 2009 11:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 w0rS57gmWHd9; Wed, 2 Dec 2009 11:30:21 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 710B23A68D9; Wed, 2 Dec 2009 11:30:21 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB2JUApt006651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 20:30:10 +0100 (MET) From: Martin Rex Message-Id: <200912021930.nB2JU9PU008221@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 2 Dec 2009 20:30:09 +0100 (MET) In-Reply-To: <4B16A1B4.2050400@extendedsubset.com> from "Marsh Ray" at Dec 2, 9 11:19: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: Chris.Newman@Sun.COM, ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 02 Dec 2009 19:30:23 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > > Even EKR admitted that implementing the update is an insignificant > > amount of work. > > > > Pushing this point, that there were interoperable implementations > > when this proposal was made in the IETF smells very much like > > a request for rubber stamping. > > My goal had been to present a usable solution along with the disclosure > of the vulnerability. When it comes to closing exploitable security > holes, a usable solution today is better than a perfect solution next > year. If that's rubber stamping to you, well sorry. I know _you_ were very open-minded about the SSLv3 interop issue from the beginning and I really value _your_ feedback in the discussion. I wrote up my proposal after realizing that some people just did not care about the obvious and serious disruptive nature for the interoperability in productive environments and existing usage scenarios of the original proposal which contained this: 4.3. SSLv3 SSLv3 does not support extensions and thus it is not possible to securely renegotiate with SSLv3. > > I am a bit disappointed that we have not had better participation from > the vendors, particularly hardware. My suspicion is that they're > reticent to discuss what they're up against either publicly or privately. One vendor that contacted me has just started to evaluate the proposals. I could conceive that there are a number of vendors/suppliers that would not know how to participate the discussion or voice their concerns. Sometimes it is as simple as there is nobody sufficiently experienced and with sufficient time available and permission from his management to enter the discussion on tls@ietf.org. > > We can't delay the solution for the large percentage of affected > deployments that are represented by vendors who did choose to > participate in the discussion for the sake of those who did not. I know that the vendors (and in particular their customers) who had been actively using the TLS renegotiation for delayed client authentication want to get a solution out there. The short-term solution to the security problem would be to disable renegotiation and request the certificate on initial handshake only. This impairs the user experience slightly, but would not kill interop completely (hmmm, it could, due to an interop-problem in WinHTTP, but I reported that in 2005...) ... unlike a requirement for a TLS extension in initial ClientHellos for a number of existing usage scenarios. So if we lack feedback from vendors, we should actively reach out and collect this feedback. The sooner the better. It's not like those vendors all live on alpha-centauri. > > >> As draft-ietf-tls-renegotiation allows use of either the cipher suite > >> value or the extension for C->S signaling, that mitigates the concern -- > >> the field can choose the mechanism that works best. > > > > I consider this a defect in draft-ietf-tls-renegotiation-01. > > There should be exactly **ONE** signaling mechanism for the initial > > ClientHello on a connection so that extensions-tolerant but > > extensions-free Servers will not be force to wade through lists > > of extensions sent by clients. > > It's a three-to-five line 'for' loop. maybe you missed the "extensions-free" part. Just like it is possible now for a significant amount of the servers out there to simply disable renegotiation, the hotfix for those servers should allow them to ship an update entirely without TLS extensions support and renegotiation still disabled. There, a single REQUIRED signaling option that does not need generic extensions support makes a HUGE difference. Search for the cipher suite (that code exists), append a short static string to ServerHello and be done with it. You are not seriously suggesting that such servers should become extensions-intolerant in order to be served the easy-to-recognize magic cipher suite value, are you? > > > That cipher suite value is definitely not added complexity. > > On the contrary, it is significantly reduced complexity. > > Well, there are now three ways to signal in an initial client hello. The > extension, the MCSV, or both. > > Some implementations will find the MCSV simpler, some the extension. It simply makes no sense to create a new protocol feature with more than one signaling mechanism. This is unnecessary complexity for the implementations and for the interop testing. The magic cipher suite signaling needs to be a MUST, the inclusion of an empty TLS extension in the ClientHello probably a SHOULD NOT. -Martin From ekr@networkresonance.com Wed Dec 2 12: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 B28613A689B for ; Wed, 2 Dec 2009 12:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=0.038, 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 7rUmbjhuBpZe for ; Wed, 2 Dec 2009 12:07:41 -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 B61C328C0DF for ; Wed, 2 Dec 2009 12:07:41 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id B69636C4367; Wed, 2 Dec 2009 12:08:49 -0800 (PST) Date: Wed, 02 Dec 2009 12:08:49 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B13F367.6040307@extendedsubset.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@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: <20091202200849.B69636C4367@kilo.networkresonance.com> 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: Wed, 02 Dec 2009 20:07:42 -0000 At Mon, 30 Nov 2009 10:31:35 -0600, Marsh Ray wrote: > > 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." Hmm... I'm not sure that's quite what we want either. Maybe "between transport layer connections"? > [Page 5] > > o For ClientHellos which are renegotiating, this field contains the > > "the renegotiated_connection field contains" Agreed. > > 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. Works for me. > > 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 see several possibilities: - One or the other and the server MUST abort if he receives both. - Either or both on initial handshakes, but RI only on rehandshakes - RI MUST be present on rehandshakes. The MCSV MAY be present but MUST be ignored. The last of these would obviously require slightly altering the "exactly the same" rule, so seems less desirable, but really any of these are easy to do. I think my preference would be for the first. > > 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. Works for me. > > 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. Works for me. > > 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? Works for me. -Ekr From mike-list@pobox.com Wed Dec 2 12:25:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF6C3A6964 for ; Wed, 2 Dec 2009 12:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfyQvKFwJcnQ for ; Wed, 2 Dec 2009 12:25:21 -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 89C8A3A6829 for ; Wed, 2 Dec 2009 12:25:21 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 67322A3BFE for ; Wed, 2 Dec 2009 15:25: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=DRYfnwKMcH4A mMLrocCa5lMLN24=; b=obFe8XQRBTtvyiZ+fmlzkp4IGieVV/Et0VNkgfsK9j8k 6ZGIYCXEx7rOxa/XO8ZqPI55d9OGREN91wi5hwan4CYCloMa/PyCv33cVP0MQuus 2PVKR0/peDsxIQSBQeopQnndCMAN4XXrvc+EFFHMg9fTO6hpXszpNp9JZEtaSwA= 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=OqlSpf v1IVl0JfJrV210ida4tPCkd11q6mu14zatJVz96sdOs1rhh5EPJKSPI76VO+TexI JKGvNYBPbEnflVpIuypgGcCY42jJJUj6MRLaphbTUgK6sl6/OqneqJb6HZtqJJjI vCcrtuqgyv7WBaGJsIHZZXBEldyEP+ixhu3NQ= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 63478A3BFD for ; Wed, 2 Dec 2009 15:25: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 061ADA3BFC for ; Wed, 2 Dec 2009 15:25:12 -0500 (EST) Message-ID: <4B16CD84.7020109@pobox.com> Date: Wed, 02 Dec 2009 12:26:44 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> In-Reply-To: <20091202200849.B69636C4367@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CBAC8E86-DF80-11DE-B029-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com 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: Wed, 02 Dec 2009 20:25:22 -0000 Eric Rescorla 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 see several possibilities: > > - One or the other and the server MUST abort if he receives both. > - Either or both on initial handshakes, but RI only on rehandshakes > - RI MUST be present on rehandshakes. The MCSV MAY be present > but MUST be ignored. > > The last of these would obviously require slightly altering the > "exactly the same" rule, so seems less desirable, but really any > of these are easy to do. I think my preference would be for the > first. Option 3 is clearly better. If a client sends the proper data within the RI extension, it seems silly for the server to abort the connection because of the presence of the cipher suite marker. It is also easier for a client to always send the cipher suite value rather than have a conditional code path. Mike From marsh@extendedsubset.com Wed Dec 2 12:34: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 63A163A692F for ; Wed, 2 Dec 2009 12:34:45 -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 QL1bzokeEwYC for ; Wed, 2 Dec 2009 12:34: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 115863A690D for ; Wed, 2 Dec 2009 12:34: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 1NFvuF-000OLn-Ib; Wed, 02 Dec 2009 20:34:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D6D78603C; Wed, 2 Dec 2009 20:34: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: U2FsdGVkX18XZRNygR6kJNSJebHou3exuzOWuwQwqW0= Message-ID: <4B16CF55.2020601@extendedsubset.com> Date: Wed, 02 Dec 2009 14:34:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912021930.nB2JU9PU008221@fs4113.wdf.sap.corp> In-Reply-To: <200912021930.nB2JU9PU008221@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: Chris.Newman@Sun.COM, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 20:34:45 -0000 Martin Rex wrote: > Marsh Ray wrote: >> Martin Rex wrote: >>> Even EKR admitted that implementing the update is an insignificant >>> amount of work. >>> >>> Pushing this point, that there were interoperable implementations >>> when this proposal was made in the IETF smells very much like >>> a request for rubber stamping. >> My goal had been to present a usable solution along with the disclosure >> of the vulnerability. When it comes to closing exploitable security >> holes, a usable solution today is better than a perfect solution next >> year. If that's rubber stamping to you, well sorry. > > I know _you_ were very open-minded about the SSLv3 interop issue from > the beginning and I really value _your_ feedback in the discussion. Thanks. I don't want to say how close I was to endorsing your proposal and why I didn't (it would sound like an underhanded debate tactic in what is still an ongoing discussion). > I wrote up my proposal after realizing that some people just did > not care about the obvious and serious disruptive nature for the > interoperability in productive environments and existing usage scenarios > of the original proposal which contained this: > > 4.3. SSLv3 > > SSLv3 does not support extensions and thus it is not possible to > securely renegotiate with SSLv3. It seemed reasonable at the time, we were under the impression that TLS 1.0 had been around for about 11 years and SSLv3 was all but dead. We had vendors participating in Project Mogul who were sitting on mountains of hard data about usage statistics and they never produced anything of value in a timely manner. Perhaps they saw profit in a breaking change, or perhaps they just didn't see the bigger picture. Thanks to someone at F5 for sharing the statistic that 22% of current traffic was SSLv3, and to the web browser vendors who all shared that they maintained fallback reconnect logic to SSLv3. >> I am a bit disappointed that we have not had better participation from >> the vendors, particularly hardware. My suspicion is that they're >> reticent to discuss what they're up against either publicly or privately. > > One vendor that contacted me has just started to evaluate the > proposals. Better late than never I suppose. > I could conceive that there are a number of vendors/suppliers > that would not know how to participate the discussion or voice their > concerns. I don't buy that. More than one just emailed me and said "hi, how do I participate?" or "who in our company has been in contact?". This isn't exactly a secret mailing list. > Sometimes it is as simple as there is nobody sufficiently > experienced and with sufficient time available and permission from > his management to enter the discussion on tls@ietf.org. IMHO, if an organization cannot not empower even a single engineer to represent its interests in an issue as important as this, it ought to get out of the internetworking business. > The short-term solution to the security problem would be to > disable renegotiation and request the certificate on initial > handshake only. This impairs the user experience slightly, It's an impossible change for a major e-retailer, particularly this time of year. > but would not kill interop completely (hmmm, it could, due to > an interop-problem in WinHTTP, but I reported that in 2005...) Something our PhoneFactor Agent software uses in some places. > ... unlike a requirement for a TLS extension in initial ClientHellos > for a number of existing usage scenarios. > > So if we lack feedback from vendors, we should actively reach > out and collect this feedback. The sooner the better. It's > not like those vendors all live on alpha-centauri. Every vendor has heard about it now. We have gotten participation from at least OpenSSL, Mozilla, Microsoft, Nokia, Cisco, Juniper, IBM, GNU TLS, F5, Sun, RSA, Opera, SAP, Apple, and others. That has got to represents the vast majority of affected SSL/TLS stacks. It would have been helpful to have had more contribution earlier in the process, we could have saved some time. >>>> As draft-ietf-tls-renegotiation allows use of either the cipher suite >>>> value or the extension for C->S signaling, that mitigates the concern -- >>>> the field can choose the mechanism that works best. >>> I consider this a defect in draft-ietf-tls-renegotiation-01. >>> There should be exactly **ONE** signaling mechanism for the initial >>> ClientHello on a connection so that extensions-tolerant but >>> extensions-free Servers will not be force to wade through lists >>> of extensions sent by clients. >> It's a three-to-five line 'for' loop. > > maybe you missed the "extensions-free" part. Possible, I'm a little slow sometimes. On the Server Hello, they only need to generate one extension which originates from within the TLS library itself. This should not trigger the need to enhance the implementation's public API to add complete generic extension support. > Just like it is possible > now for a significant amount of the servers out there to simply > disable renegotiation, the hotfix for those servers should allow > them to ship an update entirely without TLS extensions support and > renegotiation still disabled. There, a single REQUIRED signaling > option that does not need generic extensions support makes > a HUGE difference. Search for the cipher suite (that code exists), > append a short static string to ServerHello and be done with it. I don't see a big difference in "appending a short static string to ServerHello" and adding one extension. It shouldn't require adding generic support where it doesn't already exist. > You are not seriously suggesting that such servers should become > extensions-intolerant in order to be served the easy-to-recognize > magic cipher suite value, are you? Uhhh, I didn't think so. I'm probably missing something. Sorry, could you restate your idea just one more time concisely in a clean thread? It can just be to me if we don't want to keep flooding the list. >>> That cipher suite value is definitely not added complexity. >>> On the contrary, it is significantly reduced complexity. >> Well, there are now three ways to signal in an initial client hello. The >> extension, the MCSV, or both. >> >> Some implementations will find the MCSV simpler, some the extension. > > It simply makes no sense to create a new protocol feature with > more than one signaling mechanism. This is unnecessary complexity > for the implementations and for the interop testing. > > The magic cipher suite signaling needs to be a MUST, > the inclusion of an empty TLS extension in the ClientHello > probably a SHOULD NOT. My hope is that the silly MCSV (magic cipher suite value) C->S signaling will eventually go away for clients that no longer need talk to extension-ignorant servers. We need the MCSV "hack" right now, but it would be nice to not require it longer than necessary. Even today, some clients can count on extension support from the servers. They shouldn't have to use the MCSV - Marsh From mrex@sap.com Wed Dec 2 12:43: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 8B8583A683B for ; Wed, 2 Dec 2009 12:43:43 -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 7dVewbtzWiit for ; Wed, 2 Dec 2009 12:43: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 65CDE3A657C for ; Wed, 2 Dec 2009 12:43:42 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB2KhTaJ023164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 21:43:30 +0100 (MET) From: Martin Rex Message-Id: <200912022043.nB2KhS6h012733@fs4113.wdf.sap.corp> To: noskov@microsoft.com (Nasko Oskov) Date: Wed, 2 Dec 2009 21:43:28 +0100 (MET) In-Reply-To: from "Nasko Oskov" at Dec 2, 9 05:26: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] Last Call: 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: Wed, 02 Dec 2009 20:43:43 -0000 Nasko Oskov wrote: > > Pasi Eronen wrote: > > > >Note that this text is qualified by "except if the application asks for it" > >-- so applications that need this flexibility can have it. > > I think it was clear enough, but I still believe we should not be changing > such behavior as part of fixing the MiTM problem. A malicious endpoint of > either end is not something we are trying to solve. > > Changing default behavior for apps will have potential to break things that > we are not aware of. Asking each app to change to account for this new > behavior is only going to make deploying this fix slower. In principle I agree with Nasko an Marsh, the fix-renego spec should _not_ mandate any specific behaviour that has been previously undefined. I'm still convinced that the underlying security risk should be described clearly in the Security Considerations of this document, but leave it up to implementations (TLS and apps) how to address any potential security problems in this area. Although there is a known-safe behaviour, it is also one that is quite restrictive, and that might be a killer to some existing scenarios. > > I have heard of applications that rely on very short certificate lifetimes, > so a long lived TLS session with certificate renewal at some point will > cause breakage, while it will work just fine in today's world. That sounds VERY strange. There is absolutely _NO_ requirement that a TLS implementation limits the lifetime of a TLS session to the lifetime of the certificates that were used to establish this session! This only makes sense in environments where (a) the peers keep an eye on the certificate lifetime when using a TLS session and requring renegotiation when that expires and (b) a real app-level re-authentication is performed for every re-neogotiation. There are application and protocol designs where this is not done and can not be done. A certificate path validation that a TLS implementation might be doing fairly automatically is definitely _not_ a sufficient substitute for authentication. "No, you can not put a lock on our office building to prevent theft. None of our employees are carrying keys or keycards, so they would not be able to enter the building anymore." The fix is obvious and the transition period manageable. And for the penthouse of the CEO, a security guard could be an alternative solution... > > Binary comparisons of certificates is not an adequate comparison of identity > and TLS relies on the application to do the right thing when it comes to > identity. If we must keep this part, why not change it to a SHOULD to allow > vendors the flexibility of choosing which way to go? Leaving it a MUST creates > a problem for implementers that do want to implement the draft but want to > minimize breaking changes to the protocol. Binary comparison of certificates is the only check that can be reliably passed down into the TLS implementation. Anything else will require involvement of the application. Therefore it is fine for a TLS implementation to offer such functionality as an option to the application. Mandating this to be the default, retroactively many years back into the installed base has a significant disruptive potential and is probably a bad idea. -Martin From marsh@extendedsubset.com Wed Dec 2 12: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 E04BD3A695F for ; Wed, 2 Dec 2009 12:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkkfFDg1Ezfz for ; Wed, 2 Dec 2009 12:50:07 -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 162F03A690D for ; Wed, 2 Dec 2009 12:50: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 1NFw98-000Egg-LY; Wed, 02 Dec 2009 20:49:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 20C6D603C; Wed, 2 Dec 2009 20:49: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: U2FsdGVkX1+B3Yuhv95u1IKDxXJz9Jl+NM0dES/RF4Q= Message-ID: <4B16D2F1.30207@extendedsubset.com> Date: Wed, 02 Dec 2009 14:49:53 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> In-Reply-To: <20091202200849.B69636C4367@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 02 Dec 2009 20:50:08 -0000 Eric Rescorla wrote: > At Mon, 30 Nov 2009 10:31:35 -0600, > Marsh Ray wrote: >> >> [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." > > Hmm... I'm not sure that's quite what we want either. Maybe > "between transport layer connections"? I realize I'm not totally indoctrinated into the IETF terminology here, but as I read this list, it sounds like most people are thinking of the things that get spliced between as "sessions". Sessions are the things that are delimited by handshakes, right? I think of a "connection" as the thing that was continuous in SSLv2 and was split into sessions when renegotiation was added to SSLv3. Most APIs seem to have some kind of "connection object". In many object-oriented APIs this derives from the same interface as a plain TCP connection. In most usage, it seems like there's a one-to-one correspondence between TLS connections and TCP connection, even when renegotiation and session resumption is used. The wording "between transport layer connections" sounds like we're talking about TCP connections, which didn't make sense to me that two of them would have an "in between". Perhaps "across transport layer connections" is slightly better for that meaning? Even so, I'm not sure that's always necessary as it is not the essence of the attack. - Marsh From ekr@networkresonance.com Wed Dec 2 12:59: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 5F6983A68FC for ; Wed, 2 Dec 2009 12:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=0.037, 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 blJ3Y1zJm51B for ; Wed, 2 Dec 2009 12:59: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 8752F3A657C for ; Wed, 2 Dec 2009 12:59:57 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C7D3A6C4388; Wed, 2 Dec 2009 13:01:05 -0800 (PST) Date: Wed, 02 Dec 2009 13:01:05 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B16D2F1.30207@extendedsubset.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> <4B16D2F1.30207@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: <20091202210105.C7D3A6C4388@kilo.networkresonance.com> 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: Wed, 02 Dec 2009 20:59:58 -0000 At Wed, 02 Dec 2009 14:49:53 -0600, Marsh Ray wrote: > > Eric Rescorla wrote: > > At Mon, 30 Nov 2009 10:31:35 -0600, > > Marsh Ray wrote: > >> > >> [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." > > > > Hmm... I'm not sure that's quite what we want either. Maybe > > "between transport layer connections"? > > I realize I'm not totally indoctrinated into the IETF terminology here, > but as I read this list, it sounds like most people are thinking of the > things that get spliced between as "sessions". Sessions are the things > that are delimited by handshakes, right? Unfortunately, not. Sessions can span handshakes. So, for instance, if I form a TLS/TCP connection to a Web server, this establishes a session, which I can then resume in a second TLS/TCP connection thus, reusing the keyig material. It's really unfortunate terminology. Now, it's true that in your attack you are splicing two sessions together (the one formed to the attacker and the one formed to the victim client) but since the above is the context in which people think of sessions, I think that saying it that way is probably a bit confusing. > I think of a "connection" as the thing that was continuous in SSLv2 and > was split into sessions when renegotiation was added to SSLv3. Right, the problem is that connection-session is many-to-many. > Most APIs seem to have some kind of "connection object". In many > object-oriented APIs this derives from the same interface as a plain TCP > connection. > > In most usage, it seems like there's a one-to-one correspondence between > TLS connections and TCP connection, even when renegotiation and session > resumption is used. Totally. > The wording "between transport layer connections" sounds like we're > talking about TCP connections, which didn't make sense to me that two of > them would have an "in between". Right. > Perhaps "across transport layer connections" is slightly better for that > meaning? > > Even so, I'm not sure that's always necessary as it is not the essence > of the attack. Me neither. It's all very awkward to explain :( -Ekr From marsh@extendedsubset.com Wed Dec 2 14:15: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 0FA8B3A679C for ; Wed, 2 Dec 2009 14:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMSstosYHJM6 for ; Wed, 2 Dec 2009 14:15:29 -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 51F8C28C102 for ; Wed, 2 Dec 2009 14:14:29 -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 1NFxSn-000PXZ-1O; Wed, 02 Dec 2009 22:14:21 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AC758603C; Wed, 2 Dec 2009 22: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: U2FsdGVkX18W0Ijg3TGqDEemjMpZ19x3bVy5GgdPTGE= Message-ID: <4B16E6B9.6030702@extendedsubset.com> Date: Wed, 02 Dec 2009 16:14:17 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> <4B16D2F1.30207@extendedsubset.com> <20091202210105.C7D3A6C4388@kilo.networkresonance.com> In-Reply-To: <20091202210105.C7D3A6C4388@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 02 Dec 2009 22:15:30 -0000 Eric Rescorla wrote: > > Unfortunately, not. Sessions can span handshakes. Good point. So the thing which is an instance of a session on a connection that is delimited by a handshake has no name. It is these that are spliced between in the attack and are strongly bound by the fix. > So, for instance, > if I form a TLS/TCP connection to a Web server, this establishes > a session, which I can then resume in a second TLS/TCP connection > thus, reusing the keyig material. It's really unfortunate terminology. I believe session resumption reuses the master_secret, but hopefully the hello random data makes the key material unique. So AFAICT, the thing that uniquely identifies these unnamed things is the key material referred to in RFCs as (client|server)_write_(MAC_secret|key) and the Finished.verify_data. > Me neither. It's all very awkward to explain :( I think this confirms my long-held belief that good names are an essential part of the design process. - Marsh From mrex@sap.com Wed Dec 2 14: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 313EF3A68DD for ; Wed, 2 Dec 2009 14:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_BACKHAIR_33=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVrlVvlS9N0m for ; Wed, 2 Dec 2009 14:15: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 924563A691B for ; Wed, 2 Dec 2009 14:15:27 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB2MFEuZ011379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 23:15:15 +0100 (MET) From: Martin Rex Message-Id: <200912022215.nB2MFDbf018252@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 2 Dec 2009 23:15:13 +0100 (MET) In-Reply-To: <4B16A6CF.2020002@extendedsubset.com> from "Marsh Ray" at Dec 2, 9 11:41:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 02 Dec 2009 22:15:36 -0000 Marsh Ray wrote: > > Nasko Oskov wrote: > > > > I think it was clear enough, but I still believe we should not be changing > > such behavior as part of fixing the MiTM problem. A malicious endpoint of > > either end is not something we are trying to solve. > > It also represents the first toe into the water of the TLS spec > dictating the library<->app interface. There is nothing wrong with mandating certain funcationality to be made available to the application and security-relevant events to be made visible to the application (along with the exact position in the application data stream where those security-relevant events take effect). There is a lack-of-guidance defect in all of the TLS specs about the signaling of security-relevant events after the completion of the initial handshake, and that should be fixed. > > Which is a whole nother discussion I think we would be wise not to > bundle into this bug fix, as interesting as it will be. I fully agree that the fix under discussion ought to be non-disruptive to on-the-wire-interop as well as non-disruptive to TLS<->App interop and existing usage scenarios. But even for regular updates to the TLS protocol (e.g. TLS v1.3) backwards-incompatible changes are likely going to be a serious problem for the future development. During the last 14 years, whole application architectures have been built around SSL/TLS protected communication channels base on the existing semantics. So all new requirements, even for future protocol revisions, need to take the existing usage scenarios into account (except fundamentally flawed ones). We're actually lucky that we can plug the renegotiation defect so easily, because it is extremely unlikely that it has been used as a feature in existing usage scenarios, because none of the implementations exposed this "feature" for use by applications. -Martin From ekr@networkresonance.com Wed Dec 2 14:17: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 8C4F53A6836 for ; Wed, 2 Dec 2009 14:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=0.035, 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 VDprlU7oLR8h for ; Wed, 2 Dec 2009 14:17:33 -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 BBFDF3A6809 for ; Wed, 2 Dec 2009 14:17:33 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id A86C76C43B9; Wed, 2 Dec 2009 14:18:41 -0800 (PST) Date: Wed, 02 Dec 2009 14:18:41 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B16E6B9.6030702@extendedsubset.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> <4B16D2F1.30207@extendedsubset.com> <20091202210105.C7D3A6C4388@kilo.networkresonance.com> <4B16E6B9.6030702@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: <20091202221841.A86C76C43B9@kilo.networkresonance.com> 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: Wed, 02 Dec 2009 22:17:34 -0000 At Wed, 02 Dec 2009 16:14:17 -0600, Marsh Ray wrote: > > Eric Rescorla wrote: > > > > Unfortunately, not. Sessions can span handshakes. > > Good point. > > So the thing which is an instance of a session on a connection that is > delimited by a handshake has no name. Afraid not. You could imagine mirroring DTLS terminology and saying "epoch" but that's not quite what epoch means either. > It is these that are spliced between in the attack and are strongly > bound by the fix. Yep. > > So, for instance, > > if I form a TLS/TCP connection to a Web server, this establishes > > a session, which I can then resume in a second TLS/TCP connection > > thus, reusing the keyig material. It's really unfortunate terminology. > > I believe session resumption reuses the master_secret, but hopefully the > hello random data makes the key material unique. Yep. > So AFAICT, the thing that uniquely identifies these unnamed things is > the key material referred to in RFCs as > (client|server)_write_(MAC_secret|key) and the Finished.verify_data. Yep. > > Me neither. It's all very awkward to explain :( > > I think this confirms my long-held belief that good names are an > essential part of the design process. Totally. I can't tell you how much confusion the use of "session" here has caused, especially in view of the (now mostly obsolete) term "session key". -Ekr From mrex@sap.com Wed Dec 2 14:28: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 931493A6998 for ; Wed, 2 Dec 2009 14:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 nWHow-96iupd for ; Wed, 2 Dec 2009 14:28: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 8A0363A6991 for ; Wed, 2 Dec 2009 14:28:52 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB2MSgjL001309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 23:28:42 +0100 (MET) From: Martin Rex Message-Id: <200912022228.nB2MSfOF019156@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 2 Dec 2009 23:28:41 +0100 (MET) In-Reply-To: <4B16E6B9.6030702@extendedsubset.com> from "Marsh Ray" at Dec 2, 9 04:14:17 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 02 Dec 2009 22:28:53 -0000 Marsh Ray wrote: > > Eric Rescorla wrote: > > > > Unfortunately, not. Sessions can span handshakes. > > Good point. > > So the thing which is an instance of a session on a connection that is > delimited by a handshake has no name. It's only a vague concept in the TLS spec. AFAIK it is in some places refered to as "Connection State" (rfc-5246 6.1) of which there is a "current" and a "pending" incarnation, and describes the parameters for the enc/mac engine at the record layer. > > I believe session resumption reuses the master_secret, but hopefully the > hello random data makes the key material unique. That is what the spec says how the enc/mac keys are produced. The "cheapest" rekeying on a connection would be a renegotiation with a session resume. It would only re-derive session keys and avoid the public key crypto overhead. But that seems to be disabled in some implementations. It might be more difficult to process by the event-based authentication models, since a resume during renegotiation would not involve any processing of Certificate and CertificateVerify handshake messages. > > So AFAICT, the thing that uniquely identifies these unnamed things is > the key material referred to in RFCs as > (client|server)_write_(MAC_secret|key) and the Finished.verify_data. > > > Me neither. It's all very awkward to explain :( > > I think this confirms my long-held belief that good names are an > essential part of the design process. A recent feedback on my I-D requested clarification of the terminology around TLS sessions and connections. Similar to the handshake terminology (initial vs. renegotiation) I can not simply point to the official protocol spec to supply that clarification... -Martin From marsh@extendedsubset.com Wed Dec 2 14:34: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 759943A699E for ; Wed, 2 Dec 2009 14:34:54 -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 q-5mEVNF1M5Y for ; Wed, 2 Dec 2009 14:34:53 -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 B3B193A691B for ; Wed, 2 Dec 2009 14:34:53 -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 1NFxmX-000PMp-ER; Wed, 02 Dec 2009 22:34:45 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1F723603C; Wed, 2 Dec 2009 22:34:44 +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+HDRu3gKosn2pWcosLKcDNrblihLhGfic= Message-ID: <4B16EB81.20802@extendedsubset.com> Date: Wed, 02 Dec 2009 16:34:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> <4B16CD84.7020109@pobox.com> In-Reply-To: <4B16CD84.7020109@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] 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: Wed, 02 Dec 2009 22:34:54 -0000 Michael D'Errico wrote: > Eric Rescorla wrote: >> >> - RI MUST be present on rehandshakes. The MCSV MAY be present >> but MUST be ignored. >> >> The last of these would obviously require slightly altering the >> "exactly the same" rule, so seems less desirable, but really any I don't think "exactly the same" was meant so much as a rule as a description. How's this: On an initial handshake, the MCSV is semantically equivalent to an RI extension with a zero length renegotiated_connection field. For renegotiating handshakes, the TLS_RENEGO_PROTECTION_REQUEST cipher suite value MAY be sent by clients but MUST be ignored by servers. > It is also easier > for a client to always send the cipher suite value rather than have a > conditional code path. I could imagine it being a big simplification for a hardware implementation with a "hard wired" list of cipher suite values. - Marsh From nelson@bolyard.me Wed Dec 2 14:59: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 B02AB3A6946 for ; Wed, 2 Dec 2009 14:59:32 -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 C5FOXhu4xI84 for ; Wed, 2 Dec 2009 14:59:32 -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 8AF5B3A692E for ; Wed, 2 Dec 2009 14:59:32 -0800 (PST) Received: (qmail 32480 invoked from network); 2 Dec 2009 22:52:43 -0000 Received: from unknown (24.5.142.42) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 02 Dec 2009 22:52:43 -0000 Message-ID: <4B16EFBA.8060907@bolyard.me> Date: Wed, 02 Dec 2009 14:52:42 -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: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> In-Reply-To: <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 22:59:32 -0000 On 2009-12-02 09:08 PST, Chris Newman wrote: > --On December 2, 2009 15:19:53 +0100 Martin Rex wrote: >>> As draft-ietf-tls-renegotiation allows use of either the cipher suite >>> value or the extension for C->S signaling, that mitigates the concern >>> -- the field can choose the mechanism that works best. >> >> I consider this a defect in draft-ietf-tls-renegotiation-01. >> There should be exactly **ONE** signaling mechanism for the initial >> ClientHello on a connection so that extensions-tolerant but >> extensions-free Servers will not be force to wade through lists >> of extensions sent by clients. > > I'd be fine with one signaling mechanism as long as it's the mechanism > that's been standardized since 2006 and backwards-compatible with correct > implementations since 1999 (TLS 1.0). +1 > If we're misusing a cipher suite value as a protocol extensibility flag, > an issue I'm willing to compromise on despite the lack of strong evidence > it's necessary, we unfortunately need two signaling mechanisms: one > that's standard that we know will work with modern correct > implementations, and one a kludge that works with very old software, but > might break good-faith modern implementations (like the middlebox straw > man above). > >> The existing fallbacks or conservative approaches give you a hint where >> you may expect interop problems. TLS extensions are a known interop >> problem. ... for servers that have never been conformant with the standards that require them to ignore unknown extensions, yes. Another way to say this is: non-conformant servers are a known interop problem for conformant clients. That fact is manifestly obvious now, as we see attempts to retroactively codify the behavior of those non-conformant servers as we try to fix this problem. > While I've seen evidence of bugs in TLS extension handling, and backwards > compatibility fallback code that's been present in browsers since 1999, > I've seen no evidence that extensions are an interoperability problem for > correct standards-compliant TLS implementations or that such fallback code > is necessary in operation today. +1. > - Chris From dean@av8.com Wed Dec 2 15: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 438693A697E for ; Wed, 2 Dec 2009 15:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQszc39ASU+w for ; Wed, 2 Dec 2009 15:02:10 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 37B9B3A692B for ; Wed, 2 Dec 2009 15:02:10 -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 nB2N1v69012648 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Dec 2009 18:01:57 -0500 Date: Wed, 2 Dec 2009 18:01:57 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Peter Saint-Andre In-Reply-To: <4B15D9D2.3010107@stpeter.im> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Todd Glassey , ietf-honest@lists.iadl.org, rms@gnu.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 List-Id: "This is the mailing list 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, 02 Dec 2009 23:02:11 -0000 On Tue, 1 Dec 2009, Peter Saint-Andre wrote: > On 11/30/09 9:09 PM, Richard Stallman wrote: > > 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? > > Agreed, the term "intellectual property" is only bound to lead to > muddled thinking. One reason for the muddled thinking is that there is no _PROPERTY_ in any of patents, copyrights, trademarks, or trade secrets. Property is a right that time-UNLimited and transferable. Property can be tangible or intangible. In contrast, patents and copyrights are time-Limited; Even though they are transferable, they are not property. Patents and copyrights are more like a transferrable lease: A temporary asset, not a permanent asset. Trademarks are time-unlimited but can't be sold without the underlying products and services. Trademarks serve to prevent a kind of fraud on the purchaser of products and services. Trade Secrets are also time-unlimited, but serve to prevent a kind of fraud on improperly obtaining information from the secret holder. But if someone independently discovers the secret, the trade secret holder has no right to the knowledge. Embodied in the term 'intellectual property' is an implicit agenda to make patents and copyrights time-UNLimited. Its a good term if that's your agenda. Otherwise, its a bad term. I kind of agree we need an overly broad term to help with disclosure, but it should be something other than "intellectual property". Suggestions on alternative terms are appreciated. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494 From djhopwood@googlemail.com Wed Dec 2 15: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 5283C3A69A3 for ; Wed, 2 Dec 2009 15:05: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 ZHHooS-RJAQA for ; Wed, 2 Dec 2009 15:05:32 -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 179963A6836 for ; Wed, 2 Dec 2009 15:05:31 -0800 (PST) Received: by ewy6 with SMTP id 6so821080ewy.29 for ; Wed, 02 Dec 2009 15:05:21 -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=PMJvTosis/WZd587VEkcpJYofhd1z8AUmv7K2TtmEio=; b=XsxiOB5EYjZS416h+NuV+NXhoOph0iq60PsSIiiU5Vg+fSheIueAVyVeE6zgXc2WpA w50zn3nxewIuv17qLcezOcLzCI6FpslIdlthqb3I5TfG39Iwjgi7Fne4aan213Wa2lLI 45kxOpeMhs7YVez86SRLIehHH6y8dP6kvalUo= 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=lApnQKTvihkcY3gGptug/DGg5KWn99JGKWgUfZ+OSokFUiewicsEJiFFTalZ/yxP81 YQQLRtG0IY223KxJr1B3sK6VVQ2G8VaIkh6p21YGYIinrFByzq2teStNIGXOTRUoTBJO DjTF0hjMbwQ5f+++B0U4TbEY4HjwPzztG/DaI= Received: by 10.213.24.3 with SMTP id t3mr8133519ebb.40.1259795120914; Wed, 02 Dec 2009 15:05:20 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 7sm2675722eyg.33.2009.12.02.15.05.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 15:05:20 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B16F2AF.7010100@jacaranda.org> Date: Wed, 02 Dec 2009 23:05: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: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> <4B16D2F1.30207@extendedsubset.com> In-Reply-To: <4B16D2F1.30207@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8DD4CBF308114A101AD839BB" 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: Wed, 02 Dec 2009 23:05:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8DD4CBF308114A101AD839BB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > Eric Rescorla wrote: >> At Mon, 30 Nov 2009 10:31:35 -0600, >> Marsh Ray wrote: >>> [Page 3] >>>> renegotiation handshakes to the enclosing TLS channel, thus allow= ing >>>> the server to differentiate renegotiation from initial negotiatio= n, >>>> as well as preventing renegotiations from being spliced in betwee= n >>>> connections. =20 >>> "spliced in between sessions." >> Hmm... I'm not sure that's quite what we want either. Maybe=20 >> "between transport layer connections"? >=20 > I realize I'm not totally indoctrinated into the IETF terminology here,= > but as I read this list, it sounds like most people are thinking of the= > things that get spliced between as "sessions". Sessions are the things > that are delimited by handshakes, right? Yes. "between sessions" is correct; "between connections" or "between transport layer connections" is wrong. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig8DD4CBF308114A101AD839BB 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/ iF4EAREIAAYFAksW8rYACgkQWUc8YzyzqAdeqAD/Uk+i6Qjdmj2D6nNHVXVvstcq JzJG5SejWebA+Lerv6gA/201NrB889CQkaVIx8Gs2vkGP4oVYy2GHl6hCu5sW1Ir =Fei6 -----END PGP SIGNATURE----- --------------enig8DD4CBF308114A101AD839BB-- From djhopwood@googlemail.com Wed Dec 2 15:08: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 4C5A13A69AA for ; Wed, 2 Dec 2009 15:08: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 LKvoCuh1Ic-S for ; Wed, 2 Dec 2009 15:08: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 2EC523A69A9 for ; Wed, 2 Dec 2009 15:08:15 -0800 (PST) Received: by ewy6 with SMTP id 6so823414ewy.29 for ; Wed, 02 Dec 2009 15:08: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=E9Gobp3fazpugU1Z4ErWApHMwm7ap21lFeyMjquoY6E=; b=I3+8rXD9gnbyAHIKbdJfJm5FjqxDSIyZ4/hxGpKC0/vHJEjvZBU8ag0Zt4VlbppyW8 HGI1RwXKwDU4AZnrjtHwOBA5STLBageKmc+Z3e+KJJNkvrEV9ParWCv1uWrwMY6g8OBJ 5kHhzbrmrrSDw9LwrY2Hf9E66YWorogtCS9jk= 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=j+05lesKIPjfhBLZ0t623HQ4uKx+rG/Dce3i5xhdD5sl72BC7tRBKq8CiQ7yaueVuf ph0sB+v+VcXh6VBavTDUEJrkyQswKkKsnZ8/iOVgeqb4qtnHxurzYwmmp5gMgvAeTEce Iinsn408YjRm5S6vMkl2CUr/DghSnE7f14UH0= Received: by 10.213.100.161 with SMTP id y33mr816783ebn.2.1259795285135; Wed, 02 Dec 2009 15:08:05 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 10sm2696180eyz.39.2009.12.02.15.08.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 15:08:04 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B16F35A.40700@jacaranda.org> Date: Wed, 02 Dec 2009 23:08: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: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> <4B16D2F1.30207@extendedsubset.com> <4B16F2AF.7010100@jacaranda.org> In-Reply-To: <4B16F2AF.7010100@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFBD79CAE0549D49EB01A2B78" 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: Wed, 02 Dec 2009 23:08:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFBD79CAE0549D49EB01A2B78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Marsh Ray wrote: >> Eric Rescorla wrote: >>> At Mon, 30 Nov 2009 10:31:35 -0600, >>> Marsh Ray wrote: >>>> [Page 3] >>>>> renegotiation handshakes to the enclosing TLS channel, thus allo= wing >>>>> the server to differentiate renegotiation from initial negotiati= on, >>>>> as well as preventing renegotiations from being spliced in betwe= en >>>>> connections. =20 >>>> "spliced in between sessions." >>> Hmm... I'm not sure that's quite what we want either. Maybe=20 >>> "between transport layer connections"? >> I realize I'm not totally indoctrinated into the IETF terminology here= , >> but as I read this list, it sounds like most people are thinking of th= e >> things that get spliced between as "sessions". Sessions are the things= >> that are delimited by handshakes, right? >=20 > Yes. To be more precise, sessions are delimited by *full* handshakes. > "between sessions" is correct; "between connections" or > "between transport layer connections" is wrong. This is accurate. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFBD79CAE0549D49EB01A2B78 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/ iF4EAREIAAYFAksW81sACgkQWUc8YzyzqAdMAAD+Jpb860et7qPdTLZnC/kZxEbf CVC1PJA4cMvKQtuLn2gA/0HCJl/s3aP5k5pCuKZ53dMrRkkWQfQEQXZbN95tgYQA =o+8V -----END PGP SIGNATURE----- --------------enigFBD79CAE0549D49EB01A2B78-- From nelson@bolyard.me Wed Dec 2 15: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 E2AE43A69AC for ; Wed, 2 Dec 2009 15:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL5DaxGu0S-d for ; Wed, 2 Dec 2009 15:13:10 -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 EB7DE3A69A9 for ; Wed, 2 Dec 2009 15:13:09 -0800 (PST) Received: (qmail 18250 invoked from network); 2 Dec 2009 23:13:01 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 02 Dec 2009 23:13:01 -0000 Message-ID: <4B16F47D.6070809@bolyard.me> Date: Wed, 02 Dec 2009 15:13:01 -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: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com> <4B16D2F1.30207@extendedsubset.com> <20091202210105.C7D3A6C4388@kilo.networkresonance.com> <4B16E6B9.6030702@extendedsubset.com> In-Reply-To: <4B16E6B9.6030702@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Wed, 02 Dec 2009 23:13:11 -0000 On 2009-12-02 14:14 PST, Marsh Ray wrote: > Eric Rescorla wrote: >> Unfortunately, not. Sessions can span handshakes. > > Good point. > > So the thing which is an instance of a session on a connection that is > delimited by a handshake has no name. > > It is these that are spliced between in the attack and are strongly > bound by the fix. Right. >> So, for instance, >> if I form a TLS/TCP connection to a Web server, this establishes >> a session, which I can then resume in a second TLS/TCP connection >> thus, reusing the keyig material. It's really unfortunate terminology. > > I believe session resumption reuses the master_secret, but hopefully the > hello random data makes the key material unique. Right. > So AFAICT, the thing that uniquely identifies these unnamed things is > the key material referred to in RFCs as > (client|server)_write_(MAC_secret|key) and the Finished.verify_data. Yes. FWIW, NSS refers to those things collectively as the connection state, and those keys/secrets as the "connection keys". >> Me neither. It's all very awkward to explain :( > > I think this confirms my long-held belief that good names are an > essential part of the design process. +1 From marsh@extendedsubset.com Wed Dec 2 15:26: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 77AF03A6827 for ; Wed, 2 Dec 2009 15:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HTl+fhGUch6 for ; Wed, 2 Dec 2009 15:26:44 -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 A00483A67F9 for ; Wed, 2 Dec 2009 15:26:44 -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 1NFyag-00060q-8f; Wed, 02 Dec 2009 23:26:34 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CFC11603C; Wed, 2 Dec 2009 23:26: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: U2FsdGVkX19CNoh/mW35WL1PKvVI2Ij2zogmdA2Fyps= Message-ID: <4B16F7A5.30803@extendedsubset.com> Date: Wed, 02 Dec 2009 17:26:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nelson B Bolyard References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B16EFBA.8060907@bolyard.me> In-Reply-To: <4B16EFBA.8060907@bolyard.me> 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 23:26:45 -0000 Nelson B Bolyard wrote: > > ... for servers that have never been conformant with the standards that > require them to ignore unknown extensions, yes. Another way to say this is: > non-conformant servers are a known interop problem for conformant clients. > That fact is manifestly obvious now, as we see attempts to retroactively > codify the behavior of those non-conformant servers as we try to fix this > problem. Hold on now, is there any reasonable interpretation of draft-ietf-tls-renegotiation which "codifies the behavior of those non-conformant servers"? TLS implementations have every right under current specs to send and receive hello extensions. Higher-level protocols have the right even to require them. This is an urgent bug fix, not an upgrade, and as such most of us share the goal of causing absolutely minimal disruption to existing systems. Sometimes even perfectly-conformant clients are asked to connect to TCP port numbers on which a few *gasp* imperfect servers are listening. Since this sometimes results in a hung connection, the condition can only be detected after a (relatively) long timeout. The recognition of this reality, done purely in consideration of the end users of this technology, does not in any way "codify the behavior of those servers". >> While I've seen evidence of bugs in TLS extension handling, and backwards >> compatibility fallback code that's been present in browsers since 1999, >> I've seen no evidence that extensions are an interoperability problem for >> correct standards-compliant TLS implementations or that such fallback code >> is necessary in operation today. > > +1. I agree in principle. In this case though, it would be asking application code owners to rip out their fallback logic. Many of them would be willing to do it of course, but it would still fall short of our goal to engineer a fix which is deliverable as a patch only to the TLS library. - Marsh From nelson@bolyard.me Wed Dec 2 15:30: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 B7D733A68C9 for ; Wed, 2 Dec 2009 15:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 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 5cEH4CM-wAWp for ; Wed, 2 Dec 2009 15:30:38 -0800 (PST) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id ED0523A68AF for ; Wed, 2 Dec 2009 15:30:37 -0800 (PST) Received: (qmail 11378 invoked from network); 2 Dec 2009 23:30:30 -0000 Received: from unknown (24.5.142.42) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 02 Dec 2009 23:30:30 -0000 Message-ID: <4B16F895.8060702@bolyard.me> Date: Wed, 02 Dec 2009 15:30:29 -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: <200912021930.nB2JU9PU008221@fs4113.wdf.sap.corp> <4B16CF55.2020601@extendedsubset.com> In-Reply-To: <4B16CF55.2020601@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 23:30:38 -0000 On 2009-12-02 12:34 PST, Marsh Ray wrote: > Martin Rex wrote: >> 4.3. SSLv3 >> >> SSLv3 does not support extensions and thus it is not possible to >> securely renegotiate with SSLv3. > > It seemed reasonable at the time, we were under the impression that TLS > 1.0 had been around for about 11 years and SSLv3 was all but dead. I would not say that SSLv3 was "all but dead", but rather that servers that remain intolerant of versions numbers other than 0x0300 and/or intolerant of all hello extensions are all but dead. > Thanks to someone at F5 for sharing the statistic that 22% of current > traffic was SSLv3, and to the web browser vendors who all shared that > they maintained fallback reconnect logic to SSLv3. I would not characterize the fallback logic as falling back to "SSLv3". I would characterize it as falling back to that subset of SSLv3 that is both intolerant of version numbers other than 0x0300 and intolerant of any and all hello extensions. Browser vendors do indeed maintain it, but (I believe I can say this without fear of contradiction by any browser vendors) they all would like to eliminate it, and would have done so by now except for the difficulty of synchronized elimination of old browser "features". (The first browser to unilaterally eliminate an old feature loses market share.) An natural opportunity to shed this old fallback logic in a synchronized fashion comes along rarely, and this renegotiation vulnerability appears to be just such an opportunity. > IMHO, if an organization cannot not empower even a single engineer to > represent its interests in an issue as important as this, it ought to > get out of the internetworking business. Hear! HEAR! Sadly, there are numerous such companies that have such draconian penalties for engineers who make even the slightest appearance of representing their employers in fora such as this that their engineers just keep their heads down and try to do their work while escaping all public notice. This is also why so many participants here do not identify themselves with any obvious corporate or business affiliation. :-/ From nelson@bolyard.me Wed Dec 2 15:54: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 DB0DD3A689A for ; Wed, 2 Dec 2009 15:54:06 -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 vcO6Z4qVkQVX for ; Wed, 2 Dec 2009 15:54:06 -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 F405E3A67A2 for ; Wed, 2 Dec 2009 15:54:05 -0800 (PST) Received: (qmail 23047 invoked from network); 2 Dec 2009 23:53:51 -0000 Received: from unknown (24.5.142.42) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 02 Dec 2009 23:53:51 -0000 Message-ID: <4B16FE0E.5010602@bolyard.me> Date: Wed, 02 Dec 2009 15:53: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: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B16EFBA.8060907@bolyard.me> <4B16F7A5.30803@extendedsubset.com> In-Reply-To: <4B16F7A5.30803@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2009 23:54:06 -0000 On 2009-12-02 15:26 PST, Marsh Ray wrote: > Nelson B Bolyard wrote: >> ... for servers that have never been conformant with the standards that >> require them to ignore unknown extensions, yes. Another way to say this is: >> non-conformant servers are a known interop problem for conformant clients. >> That fact is manifestly obvious now, as we see attempts to retroactively >> codify the behavior of those non-conformant servers as we try to fix this >> problem. > > Hold on now, is there any reasonable interpretation of > draft-ietf-tls-renegotiation which "codifies the behavior of those > non-conformant servers"? Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF* (rather than in addition to) the RI extension is such an attempt. Such proposals now exist. > TLS implementations have every right under current specs to send and > receive hello extensions. Higher-level protocols have the right even to > require them. And some server vendors believe they have every right to reject client hellos that include any hello extensions. They now vociferously propose that we design the solution to the renegotiation vulnerability so that, even after they have patched their servers for this vulnerability, their servers can CONTINUE to reject client hellos with hello extensions. That's the issue here. > This is an urgent bug fix, not an upgrade, and as such most of us share > the goal of causing absolutely minimal disruption to existing systems. > > Sometimes even perfectly-conformant clients are asked to connect to TCP > port numbers on which a few *gasp* imperfect servers are listening. > Since this sometimes results in a hung connection, the condition can > only be detected after a (relatively) long timeout. Those servers MUST be patched now. It's a simple thing to patch them to be tolerant of (that is, to IGNORE) client hellos. But they steadfastly refuse. Instead they demand that we retroactively modify the definition of TLS to explicitly recognize and legitimize this extension-intolerant behavior. > The recognition of this reality, done purely in consideration of the end > users of this technology, does not in any way "codify the behavior of > those servers". If it effectively requires that new client products MUST implement fallback to be interoperable with conformant servers, then it most certainly does codify that behavior. >>> While I've seen evidence of bugs in TLS extension handling, and backwards >>> compatibility fallback code that's been present in browsers since 1999, >>> I've seen no evidence that extensions are an interoperability problem for >>> correct standards-compliant TLS implementations or that such fallback code >>> is necessary in operation today. >> +1. > > I agree in principle. > > In this case though, it would be asking application code owners to rip > out their fallback logic. Many of them would be willing to do it of > course, but it would still fall short of our goal to engineer a fix > which is deliverable as a patch only to the TLS library. I think you've got it backwards with respect to who is asking whom about the ripping out. The browsers WANT to rip it out. They want to eliminate the latency associated with the fallback. The attempt in some present proposals to permanently legitimize those old servers that never ignored unrecognized extensions tells the browsers that they can never rip it out. It is doubly ironic that the proponents of this approach are using the existent of fall-back and the justification for their proposal. The argument seems to be "We once forced browsers to fall back, and the browsers have never removed that feature. Now we claim the on-going existence of that fall back amounts to on-going demand for the behavior of our old servers. So, the standards MUST now explicitly provide for our servers." Regards, /Nelson From mrex@sap.com Wed Dec 2 16:02: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 D8AB93A6872 for ; Wed, 2 Dec 2009 16:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 i8oLaA7+Kl7J for ; Wed, 2 Dec 2009 16:02:17 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C64EE3A6861 for ; Wed, 2 Dec 2009 16:02:16 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB3027LJ003229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 01:02:07 +0100 (MET) From: Martin Rex Message-Id: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 3 Dec 2009 01:02:06 +0100 (MET) In-Reply-To: <4B16F35A.40700@jacaranda.org> from "David-Sarah Hopwood" at Dec 2, 9 11:08: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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 00:02:17 -0000 David-Sarah Hopwood wrote: > > >>> Marsh Ray wrote: > >>>> [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." > >>> Hmm... I'm not sure that's quite what we want either. Maybe > >>> "between transport layer connections"? > >> I realize I'm not totally indoctrinated into the IETF terminology here, > >> but as I read this list, it sounds like most people are thinking of the > >> things that get spliced between as "sessions". Sessions are the things > >> that are delimited by handshakes, right? > > > > Yes. > > To be more precise, sessions are delimited by *full* handshakes. > > > "between sessions" is correct; "between connections" or > > "between transport layer connections" is wrong. > > This is accurate. I would not call that accurate. The lack of clear terminology in the TLS protocol specs precludes a determination of accuracy. Authenticating the enclosing TLS session even protects from splicing two different "connection states (RFC-5246 6.1)" derived from the same TLS session (identified by a TLS session ID). Since we are going to re-authenticate the previous "connection state" with the same information that was used to authenticate that connection state the first time around (the verify data of the finished messages), it might be better to define the terminology before using it to describe the characteristics. The TLS protocol has a notion of TLS sessions associated with the SessionID in ClientHello and ServerHello. TLS implementations provide to applications a very different notion of "TLS sessions" -- associated with a "Session handle" or "SecurityContext handle". A renegotiation that performs a full TLS handshake results in a seperate/distinct TLS session (as identified by TLS session ID) at the TLS protocol level, but remains "the same" session (handle) from an application point of view. This has a number of security implications, including the TLS renegotiation vulnerability and the change-in-identity-without-being-reautenticated that is under controversial discussion. -Martin From marsh@extendedsubset.com Wed Dec 2 16:07: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 5D15F3A67A2 for ; Wed, 2 Dec 2009 16:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 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 qsc7GET9+i5V for ; Wed, 2 Dec 2009 16:07: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 51D043A6783 for ; Wed, 2 Dec 2009 16:07: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 1NFzEX-000Jv3-TG; Thu, 03 Dec 2009 00:07:45 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2D735603C; Thu, 3 Dec 2009 00:07:44 +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/wXdogA0vyQC0/uwxpmZJ+QUEgWxgOrJE= Message-ID: <4B17014D.8010506@extendedsubset.com> Date: Wed, 02 Dec 2009 18:07:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nelson B Bolyard References: <200912021930.nB2JU9PU008221@fs4113.wdf.sap.corp> <4B16CF55.2020601@extendedsubset.com> <4B16F895.8060702@bolyard.me> In-Reply-To: <4B16F895.8060702@bolyard.me> 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 00:07:55 -0000 Nelson B Bolyard wrote: > > I would not characterize the fallback logic as falling back to "SSLv3". > I would characterize it as falling back to that subset of SSLv3 that is > both intolerant of version numbers other than 0x0300 and intolerant of any > and all hello extensions. Browser vendors do indeed maintain it, but > (I believe I can say this without fear of contradiction by any browser > vendors) they all would like to eliminate it, and would have done so by now > except for the difficulty of synchronized elimination of old browser > "features". (The first browser to unilaterally eliminate an old feature > loses market share.) > > An natural opportunity to shed this old fallback logic in a synchronized > fashion comes along rarely, and this renegotiation vulnerability appears > to be just such an opportunity. But, deep down, how different is that from a hardware vendor saying to itself "now that my customers find themselves vulnerable, I'll make a bundle by forcing them to upgrade"? Whether his motivation is money or logical simplicty, someone who attempts to leverage a security bug into some kind of "opportunity" stands the risk of being judged quite harshly by the wider world who bought and paid for what was supposed to be working security in the first place. Sorry if this is getting too philosophical for the list. It seems to me to be somewhat relevant. - Marsh From mrex@sap.com Wed Dec 2 16:38: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 137903A67F9 for ; Wed, 2 Dec 2009 16:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 pJc7PjYGO5AF for ; Wed, 2 Dec 2009 16:38: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 B093D3A68DE for ; Wed, 2 Dec 2009 16:38:23 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB30cA5R007669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 01:38:11 +0100 (MET) From: Martin Rex Message-Id: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Thu, 3 Dec 2009 01:38:10 +0100 (MET) In-Reply-To: <4B16FE0E.5010602@bolyard.me> from "Nelson B Bolyard" at Dec 2, 9 03:53:50 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 00:38:25 -0000 Nelson B Bolyard wrote: > > > > Hold on now, is there any reasonable interpretation of > > draft-ietf-tls-renegotiation which "codifies the behavior of those > > non-conformant servers"? > > Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF* > (rather than in addition to) the RI extension is such an attempt. > Such proposals now exist. It is not the first of it's kind. The first is called rfc-5246, which is at proposed standard for a year and contains a broken TLS extensions definition called signature_algorithm, where the Server _uses_ the extension but MUST NOT confirm its use through ServerHello. If you look at the original extensions definition, then MCSV combined with a SHOULD NOT include extension RI is _well_within_ the spec: rfc-3546: - Clients typically request the use of extensions via the extended client hello message described in Section 2.1. 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. Note that for all extension types (including those defined in 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. What we're doing (looking at EKRs wording) is, that we are defining the MCSV to be "an emtpy TLS extension RI" With this definition, we are fully covered by the intent, and even mostly covered by the wording of the TLS extensions spec! But given that definition, that MCSV _is_ an empty "TLS extension RI" (one that happens to be compatible even with SSLv2 ClientHello), then it is fairly logical to _not_ completely ignore this provision in TLS extensions: There MUST NOT be more than one extension of the same type. The common sense behind this is to prevent ambiguity. You do _not_ want to have two extensions of the same type that might differ in their meaning, and you definitely want to avoid interop testing complexity. > > > TLS implementations have every right under current specs to send and > > receive hello extensions. Higher-level protocols have the right even to > > require them. > > And some server vendors believe they have every right to reject client > hellos that include any hello extensions. Unfortunately, implementations of SSLv3 have that right. It was a pretty bad idea from the IETF TLS WG to never publish an updated SSLv3 spec as an informational RFC that officially included the forward compatibility provision. > > They now vociferously propose > that we design the solution to the renegotiation vulnerability so that, > even after they have patched their servers for this vulnerability, their > servers can CONTINUE to reject client hellos with hello extensions. > That's the issue here. You're barking up the wrong tree. This is about clients that have to remain interoperable with servers that have _NOT_ been patched yet, SSLv3 Servers, SSLv2 Servers as well as servers that are never going to be patched. For software vendors it is a sad fact of life that they can not recklessly ship hotfixes that will kill existing usage scenarios in productive environments of their customers. In particular not for scenarios that have been interoperating fine for so many years, and with no substantial justification for a disruptive change. > > > This is an urgent bug fix, not an upgrade, and as such most of us share > > the goal of causing absolutely minimal disruption to existing systems. > > > > Sometimes even perfectly-conformant clients are asked to connect to TCP > > port numbers on which a few *gasp* imperfect servers are listening. > > Since this sometimes results in a hung connection, the condition can > > only be detected after a (relatively) long timeout. > > Those servers MUST be patched now. It's a simple thing to patch them to > be tolerant of (that is, to IGNORE) client hellos. This is completely unrealistic even for newest server under full maintenance that you can upgrade to the most recent TLS version. The servers and clients are all over the place and belong to thousands of entirely different organisations and will be subject to completely independent update schedules and extremely varying amounts of testing/validation before upgrading productive servers. > > But they steadfastly refuse. Instead they demand that we retroactively > modify the definition of TLS to explicitly recognize and legitimize > this extension-intolerant behavior. How about facing the real world and real world problems for an instant? > > > The recognition of this reality, done purely in consideration of the end > > users of this technology, does not in any way "codify the behavior of > > those servers". > > If it effectively requires that new client products MUST implement fallback > to be interoperable with conformant servers, then it most certainly does > codify that behavior. You're getting it backwards again. The fallbacks are already implemented. It would be unwise to leave the fallbacks vulnerable to downgrade attacks, and asking those applications that have them to remove or disable these fallbacks is a pretty bad idea. There's nothing wrong with those fallbacks. They are are real world solutions to real world problems and they were added so that customers would accept the _new_ browsers (otherwise they would have continued to use the previous browsers that didn't need the fallbacks). -Martin From mrex@sap.com Wed Dec 2 16:57: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 A440728C0EB for ; Wed, 2 Dec 2009 16:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 jqBpYKsxFAF8 for ; Wed, 2 Dec 2009 16:57:56 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id AEA023A69AA for ; Wed, 2 Dec 2009 16:57:55 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB30vhCX024891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 01:57:43 +0100 (MET) From: Martin Rex Message-Id: <200912030057.nB30vgGJ028417@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 3 Dec 2009 01:57:42 +0100 (MET) In-Reply-To: <4B15E759.7070108@extendedsubset.com> from "Marsh Ray" at Dec 1, 9 10:04: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: ekr@rtfm.com, tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 00:57:56 -0000 Marsh Ray wrote: > > > That decision MUST > > be free from policy and configuration. > > I understand the sentiment, but that wording doesn't make sense to me. my bad. The inclusion of the MCSV MUST NOT be subject to policy about the support or non-support renegotiation. If a careful/conservative supplier/vendor makes it configurable (which might be a sensible thing to do if theres a significant installed base), then it might require much more changes (potentially to the app) rather than only to the TLS implementation. A vendor like Microsoft might decide to make it configurable through a registry setting (something that might not need app changes) rather than a setting in the Advanced Tab of the Internet Options applet of the control panel (which likely requires UI changes of _some_ app coding outside of the TLS implementation). -Martin From djhopwood@googlemail.com Wed Dec 2 16:58: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 904A128C0FC for ; Wed, 2 Dec 2009 16:58: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 XIUj+1wAjQDo for ; Wed, 2 Dec 2009 16:58:22 -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 3E6D128C0F0 for ; Wed, 2 Dec 2009 16:58:22 -0800 (PST) Received: by ewy6 with SMTP id 6so904870ewy.29 for ; Wed, 02 Dec 2009 16:58: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=LeoNwgfZvWpuRZwaUkCm6lRsW5q+IFsPxxZFYaa7z9Q=; b=HDDAKYijqhBv1HwqnmSdnr8Z9CHOdciF9WZThoZVec1GmTivoLoHNKOkno7rNqF7ha puDQ/Cs8HLUB8VA8Y08Lz/Ll7hpuoNAYE3arVQLJnyiR5N56baT4yOKeh4tP+f3WbRho TJFQYj1oizT/vd+T4qAYVxoXXxbFVTVJdQuAs= 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=wN9UN9hPQJC9NztZ9dOK9n+nYltBwikJnec6XQJUfvwXNrHFoi0CeVgrkmHFiR892N BHjFHHXiKX0a7a6uEuiqk6tvXSW3RdIR4CNTFv5JzULaabJvKMfa0ClIeoX7c1wNxjXq umVbuK3AUrul2ob2L4mnB/QBjyXjE4/sdutYE= Received: by 10.213.24.9 with SMTP id t9mr8149107ebb.92.1259801889164; Wed, 02 Dec 2009 16:58:09 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 5sm2831304eyh.40.2009.12.02.16.58.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 16:58:08 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B170D1D.7070401@jacaranda.org> Date: Thu, 03 Dec 2009 00:58: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: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> In-Reply-To: <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC04CAEEBBD993B26A45ADAE3" Subject: Re: [TLS] Last Call: 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: Thu, 03 Dec 2009 00:58:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC04CAEEBBD993B26A45ADAE3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chris Newman wrote: > --On December 2, 2009 15:19:53 +0100 Martin Rex wrote: >>> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in= >>> some circumstances. That approach is untested in the field and I ha= ve >>> concerns it will negatively impact middleboxes. >> >> Huh? That sounds extremely unbelievable. >=20 > First, I'll reiterate that I found both proposals acceptable, so the > four points I made were all matters of design preference for this > situation and not issues I find strongly compelling. >=20 > The issue with middleboxes was raised by others and is a straw man.=20 > There are government standards that have a fixed list of cipher suites > and most clients can be configured to comply with those standards > today. Given the TLS standards available at the time, a middlebox whic= h > enforced the presence of just those cipher suites and no others in the > TLS handshake would reasonably be expected to be forwards compatible. That is not true. Any such middlebox would already have been broken numer= ous times by browser implementors adding new cipher suites to the list that they offer. I agree with Martin; this objection is based on a completely implausible premise. (BTW, I don't think "straw man" is what you meant to say. ) >> I consider this a defect in draft-ietf-tls-renegotiation-01. >> There should be exactly **ONE** signaling mechanism for the initial >> ClientHello on a connection so that extensions-tolerant but >> extensions-free Servers will not be force to wade through lists >> of extensions sent by clients. >=20 > I'd be fine with one signaling mechanism as long as it's the mechanism > that's been standardized since 2006 and backwards-compatible with > correct implementations since 1999 (TLS 1.0). If we're misusing a > cipher suite value as a protocol extensibility flag, an issue I'm > willing to compromise on despite the lack of strong evidence it's > necessary, we unfortunately need two signaling mechanisms: one that's > standard that we know will work with modern correct implementations, an= d > one a kludge that works with very old software, but might break > good-faith modern implementations (like the middlebox straw man above).= If the argument about middleboxes is simply wrong (which it is), then this argument is also wrong. There is no need for two client->server signalling mechanisms; it's unnecessary complexity. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigC04CAEEBBD993B26A45ADAE3 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/ iF4EAREIAAYFAksXDSUACgkQWUc8YzyzqAdhLwD+PU/33LULVBVRMo5815w0n47+ k0CuO7ectFgsCCwa73IA+QGo9n8EcetQsmqzlzWchyA46r6ik+DOFg5zbTHXNYYD =VQlE -----END PGP SIGNATURE----- --------------enigC04CAEEBBD993B26A45ADAE3-- From ekr@networkresonance.com Wed Dec 2 17:00: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 711FE3A68B5 for ; Wed, 2 Dec 2009 17:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[AWL=0.033, 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 uZNPU8Mca5UT for ; Wed, 2 Dec 2009 17:00:13 -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 9F5323A67B8 for ; Wed, 2 Dec 2009 17:00:13 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id BB32F6C47FD; Wed, 2 Dec 2009 17:01:21 -0800 (PST) Date: Wed, 02 Dec 2009 17:01:21 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp> References: <4B16FE0E.5010602@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: <20091203010121.BB32F6C47FD@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 01:00:14 -0000 At Thu, 3 Dec 2009 01:38:10 +0100 (MET), Martin Rex wrote: > > Nelson B Bolyard wrote: > > > > > > Hold on now, is there any reasonable interpretation of > > > draft-ietf-tls-renegotiation which "codifies the behavior of those > > > non-conformant servers"? > > > > Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF* > > (rather than in addition to) the RI extension is such an attempt. > > Such proposals now exist. > > It is not the first of it's kind. > > The first is called rfc-5246, which is at proposed standard for a year > and contains a broken TLS extensions definition called signature_algorithm, > where the Server _uses_ the extension but MUST NOT confirm its use > through ServerHello. To be honest, I don't recall the discussion that led to us prohibiting the server from sending this extension at all, however I don't believe it was about codifying the behavior of nonconformant servers. Rather, (and my vague memory is that Pasi proposed this text so maybe he remembers better) it was that this was a signal from the client to the server and there was an existing method for the server to signal its preferences when it wanted a signature, so there didn't seem to be much point in the server sending anything back. Note that I'm not saying this was necessarily the best design decision in the history of the universe, but I'm not sure why you're saying it's broken. -Ekr From marsh@extendedsubset.com Wed Dec 2 17:19: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 703123A67A2 for ; Wed, 2 Dec 2009 17:19:22 -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 o-SmpOFogSS2 for ; Wed, 2 Dec 2009 17:19: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 831F53A6358 for ; Wed, 2 Dec 2009 17:19:17 -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 1NG0Ld-000ACE-52; Thu, 03 Dec 2009 01:19:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 14868603C; Thu, 3 Dec 2009 01:19: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: U2FsdGVkX19pBXCATguu8t4wbjzsq8MJ5aei92oy+HI= Message-ID: <4B171209.2020307@extendedsubset.com> Date: Wed, 02 Dec 2009 19:19:05 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nelson B Bolyard References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B16EFBA.8060907@bolyard.me> <4B16F7A5.30803@extendedsubset.com> <4B16FE0E.5010602@bolyard.me> In-Reply-To: <4B16FE0E.5010602@bolyard.me> 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 01:19:22 -0000 Nelson B Bolyard wrote: > On 2009-12-02 15:26 PST, Marsh Ray wrote: >> Hold on now, is there any reasonable interpretation of >> draft-ietf-tls-renegotiation which "codifies the behavior of those >> non-conformant servers"? > > Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF* > (rather than in addition to) the RI extension is such an attempt. > Such proposals now exist. Hmm, I hadn't thought of it that way. >> TLS implementations have every right under current specs to send and >> receive hello extensions. Higher-level protocols have the right even to >> require them. > > And some server vendors believe they have every right to reject client > hellos that include any hello extensions. Personally, I believe I have the right to write a server app that rejects any kind of client I want. I wouldn't claim that such a server follows the spirit of the TLS RFCs though. Looking through RFCs 3546, 4366 though, I can't find specific wording which requires servers to ignore extensions on the client hello that they don't support. RFC 5246 says "the rules specified in [TLSEXT] require servers to ignore extensions they do not understand." But.. > [TLSEXT] Eastlake, D., 3rd, "Transport Layer Security (TLS) > Extensions: Extension Definitions", Work in Progress, > February 2008. > They now vociferously propose > that we design the solution to the renegotiation vulnerability so that, > even after they have patched their servers for this vulnerability, their > servers can CONTINUE to reject client hellos with hello extensions. > That's the issue here. I think the goal of fixing this vulnerability (which will require patching every client and server in the world) is already ambitious enough that it doesn't need to take on other causes. It is also worthwhile enough that it should specifically avoid taking on any other causes because to do so is to risk the primary goal. > Those servers MUST be patched now. It's a simple thing to patch them to > be tolerant of (that is, to IGNORE) client hellos. But they steadfastly > refuse. Instead they demand that we retroactively modify the definition > of TLS to explicitly recognize and legitimize this extension-intolerant > behavior. Well that's quite silly of them. I can't imagine why anyone would want to continue shipping a product which doesn't interoperate well when the fix is so easy. (Well, I can imagine some reasons but they're all bad ones.) >> The recognition of this reality, done purely in consideration of the end >> users of this technology, does not in any way "codify the behavior of >> those servers". > > If it effectively requires that new client products MUST implement fallback > to be interoperable with conformant servers, then it most certainly does > codify that behavior. I don't think it requires new clients to implement fallback. It just provides for clients that choose fall back or want to to be tolerant of extension-intolerant servers. Just because the fix doesn't actively break something that previously worked outside the spec doesn't mean that the spec endorses it. > I think you've got it backwards with respect to who is asking whom about > the ripping out. The browsers WANT to rip it out. There's more to TLS than just browsers. The bigger problem is that nobody knows has any idea many apps would have to be changed if we did not provide a solution for SSLv3. Nobody knows how many connections would fail if the fix required an extension on the initial hello. > They want to eliminate the latency associated with the fallback. At some point, the gain in market share from the reduced latency will be greater than the loss due to removing the fallback. > The attempt in some present > proposals to permanently legitimize those old servers that never ignored > unrecognized extensions tells the browsers that they can never rip it out. > > It is doubly ironic that the proponents of this approach are using the > existent of fall-back and the justification for their proposal. The > argument seems to be "We once forced browsers to fall back, and the browsers > have never removed that feature. Now we claim the on-going > existence of that fall back amounts to on-going demand for the behavior > of our old servers. So, the standards MUST now explicitly provide for > our servers." That is a bit ironic. Sounds to me like there probably is some customer demand for the fallback logic, or you would have ripped it out of your browser code already. Maybe that demand dried up years ago and the logic is leftover only because no one has the guts to remove it. Probably only by actually disabling it and seeing who complains can we find out how great that demand is. This bug fix is not the place for that experiment. Or perhaps you were hoping that this bug would be an external event which forced all competing browsers to remove it, that way you wouldn't have to be the only one to stick your neck out for this strict-compliance principle? This bug fix is not the time for that either. Good news though. I've talked to developers on all the major browser vendors now, and you all feel the same way about the fallback logic! Quit waiting for some cataclysmic opportunity and just do it. - Marsh From rms@gnu.org Wed Dec 2 17: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 19C643A6358 for ; Wed, 2 Dec 2009 17:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 5PwkBxK2Zr3W for ; Wed, 2 Dec 2009 17:22:39 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 4C6FE3A6893 for ; Wed, 2 Dec 2009 17:22:39 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NG0Or-0006sX-Q8; Wed, 02 Dec 2009 20:22:29 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Marsh Ray In-reply-to: <4B15E2DD.3000701@extendedsubset.com> (message from Marsh Ray on Tue, 01 Dec 2009 21:45:33 -0600) References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> <4B15D9D2.3010107@stpeter.im> <4B15E2DD.3000701@extendedsubset.com> Message-Id: Date: Wed, 02 Dec 2009 20:22:29 -0500 Cc: tglassey@earthlink.net, 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: 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: Thu, 03 Dec 2009 01:22:40 -0000 Seems to me that, in the context of asking parties to self-declare their "IP", it's better to error on the side of overly broad terminology. I think you may not appreciate how different these laws are. There is no way copyrights can restrict the use of a normal internet standard. (Someone might have a copyright on text you want to incorporate into the text of the standard, but that is a different kind of issue. Also, the IETF presumably knows who contributed that text, so there is no need to ask the public "Did any of this text come from you?") Someone somewhere is thinking he has a trademark on the first four octets of a protocol message Trademark laws concerns the way products are packaged and advertised. Since these are not packaging or advertising, I think trademark law doesn't apply to them. I am not a lawyer, and it would be interesting to ask one to make sure. But I think this is just a misunderstanding. Trade secret law can't be pertinent, since a draft standard is public knowledge already. Basically, only patent law can prohibit use of a standard. From mrex@sap.com Wed Dec 2 17: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 322EB3A6822 for ; Wed, 2 Dec 2009 17:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 w7oTsbMe14Iy for ; Wed, 2 Dec 2009 17: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 1F8713A6358 for ; Wed, 2 Dec 2009 17:30:58 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB31UkNv009028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 02:30:46 +0100 (MET) From: Martin Rex Message-Id: <200912030130.nB31UjDb000386@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Thu, 3 Dec 2009 02:30:45 +0100 (MET) In-Reply-To: <20091203010121.BB32F6C47FD@kilo.networkresonance.com> from "Eric Rescorla" at Dec 2, 9 05:01: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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 01:31:00 -0000 Eric Rescorla wrote: > > At Thu, 3 Dec 2009 01:38:10 +0100 (MET), Martin Rex wrote: > > > > Nelson B Bolyard wrote: > > > > > > > > Hold on now, is there any reasonable interpretation of > > > > draft-ietf-tls-renegotiation which "codifies the behavior of those > > > > non-conformant servers"? > > > > > > Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF* > > > (rather than in addition to) the RI extension is such an attempt. > > > Such proposals now exist. > > > > It is not the first of it's kind. > > > > The first is called rfc-5246, which is at proposed standard for a year > > and contains a broken TLS extensions definition called signature_algorithm, > > where the Server _uses_ the extension but MUST NOT confirm its use > > through ServerHello. > > To be honest, I don't recall the discussion that led to us prohibiting > the server from sending this extension at all, however I don't believe > it was about codifying the behavior of nonconformant servers. Rather, > (and my vague memory is that Pasi proposed this text so maybe he > remembers better) it was that this was a signal from the client to the > server and there was an existing method for the server to signal its > preferences when it wanted a signature, so there didn't seem to be > much point in the server sending anything back. > > Note that I'm not saying this was necessarily the best design decision > in the history of the universe, but I'm not sure why you're saying it's > broken. It breaks the negotiation architecture: C->S (Extended)ClientHello S->C (Extended)ServerHello I think that this negotiation architecture is useful. And I don't mind when MCSV is going to be the only cipher suite value that is given the "I'm an extension" status for the forseeable future (we do require WG consensus and IESG approval for this anyway). What I do not like is an overly religious attitude that is against the intention and spirit of TLS extension described by this previously quoted statement from rfc-3546: Clients typically request the use of extensions via the extended client hello message described in Section 2.1. Trying to avoid vagueness in a spec is OK, but the choice of very restrictive wording in order to avoid vagueness might turn out to be too restrictive for some real world requirements, and then it is sometimes necessary to apply common sense and re-focus on the intent behind a restriction and not hopelessly stick to the words (that were chosen with a different mindset). Too restrictive words for the "change of identities" during renegotiation may also do a lot of harm. -Martin From nelson@bolyard.me Wed Dec 2 17: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 27E123A6358 for ; Wed, 2 Dec 2009 17:35:26 -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 eXh2JYO8Wdcf for ; Wed, 2 Dec 2009 17:35:25 -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 054A63A67A2 for ; Wed, 2 Dec 2009 17:35:24 -0800 (PST) Received: (qmail 24660 invoked from network); 3 Dec 2009 01:35:13 -0000 Received: from unknown (24.5.142.42) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 03 Dec 2009 01:35:13 -0000 Message-ID: <4B1715D0.5010107@bolyard.me> Date: Wed, 02 Dec 2009 17:35: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: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp> In-Reply-To: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 01:35:26 -0000 On 2009-12-02 16:38 PST, Martin Rex wrote: > Nelson B Bolyard wrote: >>> Hold on now, is there any reasonable interpretation of >>> draft-ietf-tls-renegotiation which "codifies the behavior of those >>> non-conformant servers"? >> Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF* >> (rather than in addition to) the RI extension is such an attempt. >> Such proposals now exist. > > It is not the first of it's kind. > > The first is called rfc-5246, which is at proposed standard for a year > and contains a broken TLS extensions definition called signature_algorithm, > where the Server _uses_ the extension but MUST NOT confirm its use > through ServerHello. There are other client hello extensions that are not defined to be acknowledged by the server. that's irrelevant. > What we're doing (looking at EKRs wording) is, that we are defining > the MCSV to be "an emtpy TLS extension RI" No, and EKR's spect doesn't say that. EKR's spec says that the server responds to the two in the same way. > But given that definition, that MCSV _is_ an empty "TLS extension RI" No. Not _is_. It is convenient to your argument to imagine that it _is_. but it is not. > then it is fairly logical to _not_ completely ignore this provision in > TLS extensions: > > There MUST NOT be more than one extension of the same type. That's right. The set of encoded extensions may not contain more than one of the same type. But a cipher suite is a not an encoded extension, even when the server chooses to respond to it as if it was. >> And some server vendors believe they have every right to reject client >> hellos that include any hello extensions. > > Unfortunately, implementations of SSLv3 have that right. Or rather, one or two out of many still do. The vast majority of SSL 3.0 implementations ignore all extensions, and have for at least a decade. > It was a pretty bad idea from the IETF TLS WG to never publish > an updated SSLv3 spec as an informational RFC that officially > included the forward compatibility provision. The IETF TLS WG never officially published any SSLv3 spec. >> They now vociferously propose >> that we design the solution to the renegotiation vulnerability so that, >> even after they have patched their servers for this vulnerability, their >> servers can CONTINUE to reject client hellos with hello extensions. >> That's the issue here. > > You're barking up the wrong tree. > > This is about clients that have to remain interoperable with servers > that have _NOT_ been patched yet, SSLv3 Servers, SSLv2 Servers as well > as servers that are never going to be patched. > > For software vendors it is a sad fact of life that they can not > recklessly ship hotfixes that will kill existing usage scenarios > in productive environments of their customers. In particular not > for scenarios that have been interoperating fine for so many years, > and with no substantial justification for a disruptive change. Hmm. So software vendors cannot discontinue SSL2 support? Oh wait, they all DID! And for the very reason that SSLv2 was deemed insecure. >>> This is an urgent bug fix, not an upgrade, and as such most of us share >>> the goal of causing absolutely minimal disruption to existing systems. >>> >>> Sometimes even perfectly-conformant clients are asked to connect to TCP >>> port numbers on which a few *gasp* imperfect servers are listening. >>> Since this sometimes results in a hung connection, the condition can >>> only be detected after a (relatively) long timeout. >> Those servers MUST be patched now. It's a simple thing to patch them to >> be tolerant of (that is, to IGNORE) client hellos. > > This is completely unrealistic even for newest server under full maintenance > that you can upgrade to the most recent TLS version. There's absolutely no need to upgrade to any newer version than the version they already claim to support. They just need to ignore hello extensions, and learn to correctly negotiate whatever version they claim to support when they receive a hello with a higher version number, just as the SSL 3.0 spec always required. Ignoring extensions is typically a ONE LINE CHANGE. It's typically taking a line of code that complains if the length of the message is not exactly equal to some computed value, and changing it to allow "greater than or equal to". THat fix is a MUCH smaller change than any of the rest of the change required for the vulnerability fix, and it ansolutely eliminates all need for so-called extensionless client hellos. It means that ANY client that recieves a hello with BOTH a MCSV and an RI extension can do the right thing and not require a "fall back" just because an RI was present. > The servers and clients are all over the place and belong to thousands > of entirely different organisations and will be subject > to completely independent update schedules and extremely varying > amounts of testing/validation before upgrading productive servers. That one line of code is going to require MUCH less testing than the rest of the patch for this vulnerability. >> But they steadfastly refuse. Instead they demand that we retroactively >> modify the definition of TLS to explicitly recognize and legitimize >> this extension-intolerant behavior. > > How about facing the real world and real world problems for an instant? I am facing the real world problem: namely, servers that do not conform for years, then later demand that standards be retroactively modified to recognize and accept their behavior as having been right all along, and demand that future protocol changes preserve their right to continue to be non-conforming, thereby forcing fallback behavior on clients. >> If it effectively requires that new client products MUST implement fallback >> to be interoperable with conformant servers, then it most certainly does >> codify that behavior. > > You're getting it backwards again. > > The fallbacks are already implemented. > It would be unwise to leave the fallbacks vulnerable to downgrade attacks, If servers that are invulnerable do not require fallbacks, because they ignore extensions, and only servers that are vulnerable require fallbacks, then only clients that fall back are vulnerable. From marsh@extendedsubset.com Wed Dec 2 17:41: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 C7E283A680A for ; Wed, 2 Dec 2009 17:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMC1tJqRbvBS for ; Wed, 2 Dec 2009 17:41:00 -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 037233A6358 for ; Wed, 2 Dec 2009 17:41: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 1NG0gd-0002r7-M8; Thu, 03 Dec 2009 01:40:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 73B33603C; Thu, 3 Dec 2009 01:40: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/niO0NreKjrOFWdoQFyq6OiZVwFrF2VDo= Message-ID: <4B17171F.7000601@extendedsubset.com> Date: Wed, 02 Dec 2009 19:40:47 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B170D1D.7070401@jacaranda.org> In-Reply-To: <4B170D1D.7070401@jacaranda.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] Last Call: 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: Thu, 03 Dec 2009 01:41:00 -0000 David-Sarah Hopwood wrote: > Chris Newman wrote: >> >> The issue with middleboxes was raised by others and is a straw man. >> There are government standards that have a fixed list of cipher suites >> and most clients can be configured to comply with those standards >> today. Given the TLS standards available at the time, a middlebox which >> enforced the presence of just those cipher suites and no others in the >> TLS handshake would reasonably be expected to be forwards compatible. > > That is not true. Any such middlebox would already have been broken numerous > times by browser implementors adding new cipher suites to the list that > they offer. I agree with Martin; this objection is based on a completely > implausible premise. At PhoneFactor, some of our products do need to get in the middle of a connection (only to enhance the security of course). As a developer of such "middlebox" systems, I can assure you that we fully know what kind of job we're buying for ourselves taking that position in the protocol stream. We will look long and hard for any other option before going the route of implementing something "heroic". We just smile and fix it when we occasionally find our presence has disagreed with some (usually undocumented) assumption made by an external bit of code. We do not complain about this. To the contrary, we believe that our ability to make stuff work under all kinds of bizarre circumstances gives us something of a strategic advantage. Likewise, I sites which deploy highly-restrictive firewalls and highly-sensitive alert systems are going to be used to tweaking them regularly. It is a professional activity which they have specifically requested. - Marsh From ekr@networkresonance.com Wed Dec 2 17:47: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 C93973A680A for ; Wed, 2 Dec 2009 17:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.05 X-Spam-Level: X-Spam-Status: No, score=0.05 tagged_above=-999 required=5 tests=[AWL=0.032, 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 mtxXAVpF5B9l for ; Wed, 2 Dec 2009 17:47:08 -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 1A9293A6358 for ; Wed, 2 Dec 2009 17:47:08 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 7C9E56C4818; Wed, 2 Dec 2009 17:48:16 -0800 (PST) Date: Wed, 02 Dec 2009 17:48:16 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200912030130.nB31UjDb000386@fs4113.wdf.sap.corp> References: <20091203010121.BB32F6C47FD@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: <20091203014816.7C9E56C4818@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 01:47:08 -0000 At Thu, 3 Dec 2009 02:30:45 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > To be honest, I don't recall the discussion that led to us prohibiting > > the server from sending this extension at all, however I don't believe > > it was about codifying the behavior of nonconformant servers. Rather, > > (and my vague memory is that Pasi proposed this text so maybe he > > remembers better) it was that this was a signal from the client to the > > server and there was an existing method for the server to signal its > > preferences when it wanted a signature, so there didn't seem to be > > much point in the server sending anything back. > > > > Note that I'm not saying this was necessarily the best design decision > > in the history of the universe, but I'm not sure why you're saying it's > > broken. > > It breaks the negotiation architecture: > C->S (Extended)ClientHello > S->C (Extended)ServerHello > > I think that this negotiation architecture is useful. Hmm... It's not clear to me that that extensions always need to be a negotiation. In this particular case, the extension it being used as a signal the client's preferences and the client does not need to know that the server acknowledges them--rather it needs to deal with (or reject) whatever cert the server sends it, as would happen if the server didn't understand the extension. So, I'm not clear on how having the server send an acknowledgement in this case would be useful. Anyway, I'm not sure that there's much point in rehashing that decision now. I only responded to observe that I don't think this piece of 5246 was intended to codify nonconformant behavior. -Ekr From djhopwood@googlemail.com Wed Dec 2 17:56: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 D9EAB3A6358 for ; Wed, 2 Dec 2009 17:56: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=[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 Ox9zp41lQunT for ; Wed, 2 Dec 2009 17:56:29 -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 CC8AB3A67B3 for ; Wed, 2 Dec 2009 17:56:28 -0800 (PST) Received: by ewy6 with SMTP id 6so942076ewy.29 for ; Wed, 02 Dec 2009 17:56:20 -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=irRbqrdFRlaBm9EcsBA1bYpdjOdqTnRO0vAfzifXyYg=; b=YV2MRam1Gzmsj7PpuHScwh+EADTu7YSTLDPsuothbMXPG5Y6on3cZbM3pRMW/9ODvy GfaqXFk0LU+aPgkhcuDm9tFujKy9tzwN1CWMLZ3aSsB5AsW61NAtBadupZSrt8KYIonR XoD6LfkMtw6p0dJS3AEAxROKMVrf0z8fjQlZg= 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=KhFXrrKjNSfIb7/EbjJpZpfjV6SpNP/Z4l5jg9kTIRM9XbTFTaaoGfVHW25p9pdB// gFGNCPBljF6gjjKllZzGw6W2W5TT/VILwKhsIvnjPitKJB7woPICEccbnie72+u73dO6 CeWGg9iqzn6Z7o8jGGpoqkIc2JT+ESALtoVac= Received: by 10.213.25.75 with SMTP id y11mr937344ebb.49.1259805380458; Wed, 02 Dec 2009 17:56:20 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm1078018ewy.13.2009.12.02.17.56.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 17:56:19 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B171AC0.6090403@jacaranda.org> Date: Thu, 03 Dec 2009 01:56: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: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> In-Reply-To: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB61F92A2E9A1FFC489EDDB31" Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 01:56:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB61F92A2E9A1FFC489EDDB31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > David-Sarah Hopwood wrote: >>>>> Marsh Ray wrote: >>>>>> [Page 3] >>>>>>> renegotiation handshakes to the enclosing TLS channel, thus al= lowing >>>>>>> the server to differentiate renegotiation from initial negotia= tion, >>>>>>> as well as preventing renegotiations from being spliced in bet= ween >>>>>>> connections. =20 >>>>>> "spliced in between sessions." >>>>> Hmm... I'm not sure that's quite what we want either. Maybe=20 >>>>> "between transport layer connections"? >>>> I realize I'm not totally indoctrinated into the IETF terminology he= re, >>>> but as I read this list, it sounds like most people are thinking of = the >>>> things that get spliced between as "sessions". Sessions are the thin= gs >>>> that are delimited by handshakes, right? >>> Yes. >> To be more precise, sessions are delimited by *full* handshakes. >> >>> "between sessions" is correct; "between connections" or >>> "between transport layer connections" is wrong. >> This is accurate. >=20 > I would not call that accurate. The lack of clear terminology in > the TLS protocol specs precludes a determination of accuracy. On reflection you're right. TLS 1.2 defines what a "session" is in section 7, and it is not consistent with what I said above (because there may be multiple instances of the same session). The concept we want is precisely a "channel", as defined in the channel bindings draft and in RFC 5056. Fortunately the TLS RFC does not already use this term in a way that would be inconsistent with this meaning. The channels we want to use here are identified by the contents of a pair of Finished messages, i.e. each Finished message pair starts a new channel. > Authenticating the enclosing TLS session even protects from splicing > two different "connection states (RFC-5246 6.1)" derived from the > same TLS session (identified by a TLS session ID). Right. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB61F92A2E9A1FFC489EDDB31 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/ iF4EAREIAAYFAksXGscACgkQWUc8YzyzqAcxbwEAlyHmtVC3/d3c7QQ4cFCGfUW2 PNPrYLxG73KPL8xO5IgA/3XSHgGPPbi8V2qw0w5ewy26dwIIalYJPTJwoC8muGRO =a6OV -----END PGP SIGNATURE----- --------------enigB61F92A2E9A1FFC489EDDB31-- From mickgray@au1.ibm.com Wed Dec 2 17:59: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 305C93A68C6 for ; Wed, 2 Dec 2009 17:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[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 cqNmgGfJd4Nh for ; Wed, 2 Dec 2009 17:59:17 -0800 (PST) Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by core3.amsl.com (Postfix) with ESMTP id CF3D63A6863 for ; Wed, 2 Dec 2009 17:59:16 -0800 (PST) Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB31x1Qt017618 for ; Thu, 3 Dec 2009 12:59:01 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB31tTQF1470654 for ; Thu, 3 Dec 2009 12:55:29 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB31x64w032177 for ; Thu, 3 Dec 2009 12:59:06 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB31x51f032171; Thu, 3 Dec 2009 12:59:05 +1100 In-Reply-To: <4B16FE0E.5010602@bolyard.me> To: Nelson B Bolyard X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Thu, 3 Dec 2009 11:58:58 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 03/12/2009 13:06:00 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 01:59:18 -0000 DQpOZWxzb24gQiBCb2x5YXJkIDxuZWxzb25AYm9seWFyZC5tZT4gd3JvdGU6DQoNCj4gT24gMjAw OS0xMi0wMiAxNToyNiBQU1QsIE1hcnNoIFJheSB3cm90ZToNCj4gPiBOZWxzb24gQiBCb2x5YXJk IHdyb3RlOg0KPiA+PiAgLi4uIGZvciBzZXJ2ZXJzIHRoYXQgaGF2ZSBuZXZlciBiZWVuIGNvbmZv cm1hbnQgd2l0aCB0aGUgc3RhbmRhcmRzDQp0aGF0DQo+ID4+IHJlcXVpcmUgdGhlbSB0byBpZ25v cmUgdW5rbm93biBleHRlbnNpb25zLCB5ZXMuICBBbm90aGVyIHdheSB0bw0KPiBzYXkgdGhpcyBp czoNCj4gPj4gbm9uLWNvbmZvcm1hbnQgc2VydmVycyBhcmUgYSBrbm93biBpbnRlcm9wIHByb2Js ZW0gZm9yIGNvbmZvcm1hbnQNCmNsaWVudHMuDQo+ID4+IFRoYXQgZmFjdCBpcyBtYW5pZmVzdGx5 IG9idmlvdXMgbm93LCBhcyB3ZSBzZWUgYXR0ZW1wdHMgdG8NCnJldHJvYWN0aXZlbHkNCj4gPj4g Y29kaWZ5IHRoZSBiZWhhdmlvciBvZiB0aG9zZSBub24tY29uZm9ybWFudCBzZXJ2ZXJzIGFzIHdl IHRyeSB0byBmaXgNCnRoaXMNCj4gPj4gcHJvYmxlbS4NCj4gPg0KPiA+IEhvbGQgb24gbm93LCBp cyB0aGVyZSBhbnkgcmVhc29uYWJsZSBpbnRlcnByZXRhdGlvbiBvZg0KPiA+IGRyYWZ0LWlldGYt dGxzLXJlbmVnb3RpYXRpb24gd2hpY2ggImNvZGlmaWVzIHRoZSBiZWhhdmlvciBvZiB0aG9zZQ0K PiA+IG5vbi1jb25mb3JtYW50IHNlcnZlcnMiPw0KPg0KPiBBbnkgcHJvcG9zYWwgd2hpY2ggd291 bGQgaGF2ZSB1cyBzZW5kIHRoZSAiTWFnaWMgQ2lwaGVyIFN1aXRlIiAqSU5TVEVBRA0KT0YqDQo+ IChyYXRoZXIgdGhhbiBpbiBhZGRpdGlvbiB0bykgdGhlIFJJIGV4dGVuc2lvbiBpcyBzdWNoIGFu IGF0dGVtcHQuDQo+IFN1Y2ggcHJvcG9zYWxzIG5vdyBleGlzdC4NCj4NCg0KSU1ITyB0aGVyZSBp cyBhIHBvc3NpYmlsaXR5IG9mIHNvbWUgdmVyeSBzbWFsbCBidXQgcmVncmV0dGFibHkgbm9uIHpl cm8NCm51bWJlciBvZiBvbGQgU2VydmVycyBzdGlsbCBpbiBleGlzdGVuY2UgKHBlcmhhcHMgaW4g YW4gaW50ZXJuYWwgbmV0d29yaw0KZG9pbmcgc2VjdXJlIExEQVApIHRoYXQgbWlnaHQgbm90IGJl IGFibGUgdG8gdG9sZXJhdGUgZGF0YSBmb2xsb3dpbmcgYQ0KQ2xpZW50IGhlbGxvLiAgQ29uc2lk ZXIgaWYgYSB1c2VyIHdlcmUgdG8gYXBwbHkgdGhpcyBzZWN1cml0eSBmaXggYW5kDQp1cGRhdGUg dGhlIGNsaWVudCBjb2RlIHRoYXQgY29ubmVjdHMgdG8gdGhlc2Ugc2VydmVycyBpbiBhIHByb2R1 Y3Rpb24NCmVudmlyb25tZW50IHRoZW4gdGhlcmUgaXMgcmlzayB0aGF0IHRoZSBwcm9kdWN0aW9u IHN5c3RlbSB3aWxsIHN0b3ANCndvcmtpbmcuICBUaGlzIHdvdWxkIG1vc3QgbGlrZWx5IGJlIGR1 ZSB0byBodW1hbiBlcnJvciBpbiB0aGF0IHRoZSBTZXJ2ZXJzDQp3ZXJlIG5vdCB1cGRhdGVkIGlu IGNvbmp1bmN0aW9uIHdpdGggdGhlIENsaWVudHMsIGFzIHRoZSB1c2VyIG1pZ2h0IG5vdA0Ka25v dyB0aGF0IG9uZSBwcm9kdWN0IHVwZGF0ZSByZXF1aXJlcyBhbm90aGVyIHByb2R1Y3QgdXBkYXRl IHBvc3NpYmx5IGZyb20NCmEgZGlmZmVyZW50IHZlbmRvciwgYnV0IHRoaXMgaXMgaG93IGFkdmVy c2UgZXZlbnRzIHN0YXJ0LiAgSW4gdGhpcyBjYXNlIHRoZQ0Kc2VjdXJpdHkgZml4IGhhcyBicm9r ZW4gdGhlIHNlY3VyaXR5IHByaW5jaXBhbCBvZiDigJhhdmFpbGFiaWxpdHnigJkuICBJTUhPIHRo ZQ0Kc2VjdXJpdHkgZml4IG11c3QgZW5zdXJlIHRoYXQg4oCYYXZhaWxhYmlsaXR54oCZIGlzIG5v dCBhZHZlcnNlbHkgaW1wYWN0ZWQgZm9yDQphbnkgU1NML1RMUyB1c2VyLCBldmVuIGlmIHRoYXQg bnVtYmVyIG9mIHVzZXJzIHdobyBtaWdodCBiZSBpbXBhY3RlZCBpcw0KdGlueS4gICBBZGRpdGlv bmFsbHksIEkgY2FuIG5vdCBzZWUgaG93IGFueSBTU0wgY29uc3VtZXIgaXMgZ29pbmcgdG8gYmUN CnBsZWFzZWQgd2l0aCB0aGUgaWRlYSB0aGF0IGFwcGx5aW5nIGEgZml4IGFnYWluc3QgYSBwb3Nz aWJsZSByaXNrIGNhbiBjYXVzZQ0KYSByZWFsIGZhaWx1cmUgaW4gYSBwcm9kdWN0aW9uIGVudmly b25tZW50LiBUaGlzIHJpc2sgaXMgZHVlIHRvIGNsaWVudA0KYmVoYXZpb3IgY2hhbmdlIGFzIGEg cmVzdWx0IG9mIGFwcGx5aW5nIHRoZSBmaXguICBJTUhPIHRoZSBwcm9wb3NlZA0KQ2lwaGVyU3Vp dGUgc2lnbmFsaW5nIG1ldGhvZCBwcm92aWRlcyBhbiBvcGVyYXRpb25hbGx5IHNhZmUgcHJvYmUg b2YgU2VydmVyDQpjYXBhYmlsaXR5IGR1ZSB0byBubyBjaGFuZ2UgaW4gQ2xpZW50SGVsbG8gcHJv dG9jb2wgYmVoYXZpb3IuICBJIHdvdWxkIGdvDQpzbyBmYXIgYXMgdG8gcmVjb21tZW5kIHRoYXQg dGhpcyBtZXRob2QgYmUgdXNlZCBleGNsdXNpdmVseSB1bmxlc3MgdGhlDQpDbGllbnQgaW4gcXVl c3Rpb24gaXMgYWxyZWFkeSBzZW5kaW5nIGV4dGVuc2lvbnMgZHVyaW5nIENsaWVudEhlbGxvLCBp bg0Kd2hpY2ggY2FzZSB0aGUgQ2xpZW50IHNob3VsZCBzZW5kIHRoZSBSSSBFeHRlbnNpb24gaW5z dGVhZCBvZiB0aGUNCkNpcGhlclN1aXRlIGFzIGl0IGlzIHRoZW4gY2xlYXIgdGhhdCBhcHBseWlu ZyB0aGlzIHNlY3VyaXR5IGZpeCBhbmQgc2VuZGluZw0KdGhlIFJJIEV4dGVuc2lvbiBkb2VzIG5v dCByZXN1bHQgaW4gYSBjbGllbnQgYmVoYXZpb3IgY2hhbmdlLg0KDQotIE1pY2sNCg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGlu ZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rscw== From marsh@extendedsubset.com Wed Dec 2 18:20: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 78B6228C105 for ; Wed, 2 Dec 2009 18:20:07 -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 8XPl1sQSsIn9 for ; Wed, 2 Dec 2009 18:20: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 B1F0F28C10E for ; Wed, 2 Dec 2009 18:19: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 1NG1Hv-0008wg-Og; Thu, 03 Dec 2009 02:19:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 12440603C; Thu, 3 Dec 2009 02: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: U2FsdGVkX18tBqV35RvHjVcfTeY7oepvyWLd2QKiXiU= Message-ID: <4B172027.9030200@extendedsubset.com> Date: Wed, 02 Dec 2009 20:19:19 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rms@gnu.org References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> <4B15D9D2.3010107@stpeter.im> <4B15E2DD.3000701@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: tglassey@earthlink.net, 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 List-Id: "This is the mailing list 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, 03 Dec 2009 02:20:07 -0000 Richard Stallman wrote: > Seems to me that, in the context of asking parties to self-declare their > "IP", it's better to error on the side of overly broad terminology. > > I think you may not appreciate how different these laws are. There is > no way copyrights can restrict the use of a normal internet standard. > [...] > Someone somewhere is thinking he has a trademark on the first four > octets of a protocol message > > Trademark laws concerns the way products are packaged and advertised. > Since these are not packaging or advertising, I think trademark law > doesn't apply to them. I am not a lawyer, and it would be interesting > [...] http://www.chillingeffects.org/trademark/notice.cgi?NoticeID=203 > Basically, only patent law can prohibit use of a standard. You've missed or ignored my point, which is not about actual law, but about facilitating communication: different terminology suits different purposes. The main purpose of having the disclosure discussion in an open standards effort is to prevent problems later. You want parties to share everything that they think could be relevant, but more importantly they have to not go away thinking that there was something that they weren't obligated to disclose. It may suit your purposes better for there to be an actual legal confrontation in which you prevail, but for a standards effort anything like that would be at best a major headache. - Marsh From mrex@sap.com Wed Dec 2 18:25: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 A15BC28C0DF for ; Wed, 2 Dec 2009 18:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 wDxpPjYaehEz for ; Wed, 2 Dec 2009 18:25: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 840123A6883 for ; Wed, 2 Dec 2009 18:25:35 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB32PIOp026218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 03:25:18 +0100 (MET) From: Martin Rex Message-Id: <200912030225.nB32PHkW003916@fs4113.wdf.sap.corp> To: mickgray@au1.ibm.com (Michael Gray) Date: Thu, 3 Dec 2009 03:25:17 +0100 (MET) In-Reply-To: from "Michael Gray" at Dec 3, 9 11:58: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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 02:25:36 -0000 Michael Gray wrote: > > I would go > so far as to recommend that this method be used exclusively unless the > Client in question is already sending extensions during ClientHello, in > which case the Client should send the RI Extension instead of the > CipherSuite as it is then clear that applying this security fix and sending > the RI Extension does not result in a client behavior change. I'm sorry to disagree on this particular point. (I've indicated this to Marsh previously, but not yet replied): If a client does not _always_ include the MCSV, it is making life extra hard for extensions-tolerant but extensions-less SSLv3/TLSv1.0/TLSv1.1 servers that do themselves _not_ need renegotation. An SSLv3 server that is already extensions-tolerant but does not contain code to parse TLS extensions would have two options: 1) insist on clients to connect with extension-less ClientHellos so that the necessary code changes to find the MCSV are tiny. 2) adopt generic TLS extensions code in order to find the TLS extension RI among a lot of other TLS extensions. (1) is definitely much less work code-wise, but would amount to a recommendation to effectively become extensions-intolerant. (2) is more work to implement (implementing 1 is still necessary, mind you) and creates additional complexity for interop-testing We do *NOT* need more than one signaling mechanism, so the use of MCSV needs to be a MUST and the use of an empty TLS extension RI on the initial ClientHello needs to be a SHOULD NOT. The TLS extension RI can not be blindly asserted anyway, since it needs to be filled with very specific data on renegotiation. The client should _ALWAYS_ include the MCSV, even when sending a TLS extension RI that includes the verify_data from Client.Finished, so that an updated SSLv3/TLSv1.0/TLSv1.1 server that is extensions-tolerant but extension-less and does not implement renegotiation can easily detect by presence of MCSV when a updated client's renegotiation is proxied into the servers initial handshake. Having updated clients _always_ include MCSV is really not difficult to implement. And as previously mentioned, the purpose of the MCSV is the clients desire to _not_ have his handshake be accepted for old renegotiation with an updated server (independent of whether the server sees or supports renegotiation). -Martin From yngve@opera.com Wed Dec 2 18:31: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 A76123A698F for ; Wed, 2 Dec 2009 18:31:18 -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 WAaBPljQxs94 for ; Wed, 2 Dec 2009 18:31:17 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 6CED23A6909 for ; Wed, 2 Dec 2009 18:31:17 -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 nB32TBg3005649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Dec 2009 02:29:13 GMT Date: Thu, 03 Dec 2009 03:30:38 +0100 To: "Marsh Ray" , "Nelson B Bolyard" 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: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B16EFBA.8060907@bolyard.me> <4B16F7A5.30803@extendedsubset.com> <4B16FE0E.5010602@bolyard.me> <4B171209.2020307@extendedsubset.com> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4B171209.2020307@extendedsubset.com> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 02:31:18 -0000 On Thu, 03 Dec 2009 02:19:05 +0100, Marsh Ray wrote: > Sounds to me like there probably is some customer demand for the > fallback logic, or you would have ripped it out of your browser code > already. Maybe that demand dried up years ago and the logic is leftover > only because no one has the guts to remove it. No, there is no "demand" for the fallback, as such. It is just that our users want to be able to use the browser to access their websites without problem, such as to be able to go to sites like https://www.emigrantdirect.com/ (Try that one in Opera 8.x with TLS 1.1 enabled; I have not investigated, but it is either reacting to TLS 1.1 being offered, which is my guess based one the profile, as it seems to be using the wrong version number when checking the premaster secret, or the extensions; I found it while going through just a couple of dozen HTTPS sites whose URLs I had available). So the "demand" has not dried up. And for the record: I am very much in favour of all browsers removing the fallbacks; they add way too much overhead and complexity, and make the clients vulnerable to version downgrade attacks. I may have mentioned this before, but Opera 10 is shipping with the ability to, through an autoupdate functionality, turn off MD5, SHA-1 support in certificates, as well as disabling SSL v3, if/when that should prove necessary. Additionally: We will probably soon deploy something similar to disable being lenient with the renegotiation problem, and with the fallback. > Probably only by actually > disabling it and seeing who complains can we find out how great that > demand is. Which is why SSL v2 and 40/56 bit encryption didn't get disabled until Opera 9 (2006), since important sites were still using them while we were betatesting 8.0 in 2004/2005, which we discovered by disabling the functionality. -- 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 Dec 2 18:45: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 B95C33A68B4 for ; Wed, 2 Dec 2009 18:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 zlJSM6UcpVQU for ; Wed, 2 Dec 2009 18:45:22 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id BCD9D3A69B0 for ; Wed, 2 Dec 2009 18:45:21 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB32j7eZ009349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 03:45:07 +0100 (MET) From: Martin Rex Message-Id: <200912030245.nB32j6Ra004974@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 3 Dec 2009 03:45:06 +0100 (MET) In-Reply-To: from "Yngve N. Pettersen" at Dec 3, 9 03:30: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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 02:45:22 -0000 Yngve N. Pettersen wrote: > > Which is why SSL v2 and 40/56 bit encryption didn't get disabled until > Opera 9 (2006), since important sites were still using them while we were > betatesting 8.0 in 2004/2005, which we discovered by disabling the > functionality. Changing behaviour in a disruptive fashion on a new product release is OK (but often a nuisance for customers -- which is why so many users are _not_ using the most recent version of a lot of software). "The cutting edge is often the bleeding edge." Sneaking anything of disruptive nature into a hotfix for an installed base is somewhere between unwise and irresponsible and may open a software vendor to legal liabilities in some jurisdictions. There is a reason why most of the Office PCs in companies don't feed their updates/hotfixes directly from WindowsUpdates, but instead from an update server run by the local IT department of the company, which validates that hotfix in important usage scenarios before deploying it throughout their entire infrastructure. None of the software that *I* use is on automatic update. I'm sick of analyzing and reporting interop&compatibility problems that would often occur at times when I really don't have any resources to bother with them. -Martin From djhopwood@googlemail.com Wed Dec 2 18:47: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 26AE13A6926 for ; Wed, 2 Dec 2009 18:47: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 zshL387Fm6gt for ; Wed, 2 Dec 2009 18:47:30 -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 B88373A69B0 for ; Wed, 2 Dec 2009 18:47:29 -0800 (PST) Received: by ewy6 with SMTP id 6so971993ewy.29 for ; Wed, 02 Dec 2009 18:47: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=sO21Qf17cYKAkjhqHU+Ntxbg7zQUEry1RFmWqk09ISc=; b=Xkyp8c2463a81OqzAAjo1eW7HxTa/noLu+96j8BTEXMr/anYWVQUeL3aPejoUgoaEx lRx2GKSI0VOq2OdEBnddt8wvDTlYe8T2ioHEJEkItHRxEu8prjuuVbCKuHhlGtMiOm16 yabq0Etommt+D7tuXXslAFURKxKbb3+/Mgw8c= 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=n1xkBlElDxyFxuoRkvA5OTN1URvdm8neCiS00TqVzV81Ii9f2a0SOkYJIJrzcQVdi3 nXVjv4DNoSXehpuMYPyXzwrR6THornlkPR49poKNnJzBSoTCJGihU/VXYYu9GrK6Ixlq w08qCnJMMtyGuYeT8Ldm5TqeUGvTWzDsEN6EE= Received: by 10.213.23.201 with SMTP id s9mr990324ebb.5.1259808436860; Wed, 02 Dec 2009 18:47:16 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm1089566ewy.9.2009.12.02.18.47.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 18:47:16 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1726AC.7060102@jacaranda.org> Date: Thu, 03 Dec 2009 02:47: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: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp> In-Reply-To: <200912030038.nB30cApZ027373@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7F9778C3CAF2F1FC7431BB4A" Subject: Re: [TLS] Last Call: 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: Thu, 03 Dec 2009 02:47:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F9778C3CAF2F1FC7431BB4A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Nelson B Bolyard wrote: >> someone wrote: [...] >>> This is an urgent bug fix, not an upgrade, and as such most of us sha= re >>> the goal of causing absolutely minimal disruption to existing systems= =2E >>> >>> Sometimes even perfectly-conformant clients are asked to connect to T= CP >>> port numbers on which a few *gasp* imperfect servers are listening. >>> Since this sometimes results in a hung connection, the condition can >>> only be detected after a (relatively) long timeout. >> >> Those servers MUST be patched now. It's a simple thing to patch them = to >> be tolerant of (that is, to IGNORE) client hellos. Yes, they must. > This is completely unrealistic even for newest server under full mainte= nance > that you can upgrade to the most recent TLS version. Martin, you know very well the difference between upgrading to TLS 1.2 vs= making a server TLS- and extension-tolerant, so please don't continue to conflate them. ---- IMO, the world would be a better place if client implementors all strippe= d out fallbacks for TLS- and extension-intolerance and just let any remaini= ng noncompliant servers break. Those servers would get fixed if anyone cared= about them, probably also patching many other exploitable security vulnerabilities in the process. Unfortunately, client implementors -- and in particular web browser implementors -- are not likely to agree with me on that point. I've had enough arguments with some of them about other security vs backward-compatibility issues to see that they have a fundamentally different view of these things. As long as there are some client implementors who *perceive* workarounds for extension-intolerance to be necessary, and as long as I and others can't *prove* that the proportion of intolerant servers is negligable (which is trying to prove a negative, given all the servers behind firewalls that we can't test), then the workarounds will remain. Therefore, the fix for the renegotiation flaw will be simpler if it introduces no reason to use such workarounds, and if the client->server signal can be used on all connections (including fallback connections if the client implements them for any other reason). If the spec is able to say that it MUST be used on all connections, then that greatly simplifies the security analysis -- which is critical because we don't have much time to do that analysis. This argues for allowing *only* the magic ciphersuite for C->S signalling= =2E It's ugly, but it's less ugly than having multiple ways to signal the same thing, requiring more code paths and more to go wrong. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig7F9778C3CAF2F1FC7431BB4A 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/ iF4EAREIAAYFAksXJrQACgkQWUc8YzyzqAf+twD/dY7C3zkihC/SYpbgi/IzTXMg zJ4AkKMzjcrKHolvAsoBAJgfmm+rljLeDyFtQSQB3UfWUk5Qu7E+VX9FSb+9htnB =Ih/Z -----END PGP SIGNATURE----- --------------enig7F9778C3CAF2F1FC7431BB4A-- From djhopwood@googlemail.com Wed Dec 2 19:58: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 1C33D28C11D for ; Wed, 2 Dec 2009 19:58: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 EVNvSqoONA2t for ; Wed, 2 Dec 2009 19:58:16 -0800 (PST) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 10A503A682F for ; Wed, 2 Dec 2009 19:58:15 -0800 (PST) Received: by ewy2 with SMTP id 2so28771ewy.28 for ; Wed, 02 Dec 2009 19:58:04 -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=UZkCorsTP/pMSFEQsUSOQOpo2mSyI4B7wK1TBXDRAK4=; b=bRsiBrNwpv8bXV0dem0FDB5mIyiHDyM2gwC2yhj/PDA7qnxQjnZg0I4py3PQclna3D ehk5i7HaHvJrIRtsLZyTcrEi8RbYePQ30OM2BhnJsJ14cLmDTpat39ziqrQCmn5LA/dH xg78+4f9NITpixdQZ7sy+TFI0GBP7cCHDeFuo= 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=essOEswqdg3QChhKfK0IjhCeGhe78qEND1vPenc0oa3lreQvFCoMU1fBNtghrCCEwM XSoeIE58x8qw4nmdKXE8XzCyu5IlehE8++gpPazfcF7ukJucfbPLVh/3V1OA71JA0sAW oZzZh0ctPkGc5/2+YImLdMjafDnT8vJjsyDE4= Received: by 10.213.25.66 with SMTP id y2mr8466080ebb.97.1259812684852; Wed, 02 Dec 2009 19:58:04 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 24sm2999067eyx.6.2009.12.02.19.58.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 19:58:04 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B173743.7070205@jacaranda.org> Date: Thu, 03 Dec 2009 03:57: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: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC5CC7D89B82622CAAB6C2C53" Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 03:58:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5CC7D89B82622CAAB6C2C53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael Gray wrote: > [...] Consider if a user were to apply this security fix and > update the client code that connects to these servers in a production > environment then there is risk that the production system will stop > working. This would most likely be due to human error in that the Serv= ers > were not updated in conjunction with the Clients, as the user might not= > know that one product update requires another product update possibly f= rom > a different vendor, but this is how adverse events start. In this case= the > security fix has broken the security [principle] of =E2=80=98availabili= ty=E2=80=99. IMHO the > security fix must ensure that =E2=80=98availability=E2=80=99 is not adv= ersely impacted for > any SSL/TLS user, even if that number of users who might be impacted is= > tiny. I don't believe any fix is possible for this vulnerability that would guarantee not to affect availability in any cases. Availability is indeed= an important security property, but TLS rightly focusses on providing confidentiality and integrity even if that may sometimes be at the expens= e of availability. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigC5CC7D89B82622CAAB6C2C53 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/ iF4EAREIAAYFAksXN0oACgkQWUc8YzyzqAfUyQEAg4XbsuhrpGSTOBtg5KX4//x7 6OdFMV1ylWCSckODaEUA/AvN1T4lcqHVK4bICR6n38kyImqwDPJwXc8at37CCq76 =52i/ -----END PGP SIGNATURE----- --------------enigC5CC7D89B82622CAAB6C2C53-- From Chris.Newman@Sun.COM Wed Dec 2 20:44: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 9F94B3A690B for ; Wed, 2 Dec 2009 20:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.060, 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 qIMelJgIQlUB for ; Wed, 2 Dec 2009 20:44:54 -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 0BF7D3A67E4 for ; Wed, 2 Dec 2009 20:44:53 -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 nB34ijFL026507 for ; Wed, 2 Dec 2009 20:44:46 -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 <0KU2009007RDU400@fe-sfbay-09.sun.com> for tls@ietf.org; Wed, 02 Dec 2009 20:44:45 -0800 (PST) Received: from [192.168.15.4] ([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 <0KU200FLZ7UJJO70@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 20:44:45 -0800 (PST) Date: Wed, 02 Dec 2009 20:44:08 -0800 From: Chris Newman In-reply-to: <4B170D1D.7070401@jacaranda.org> Sender: Chris.Newman@Sun.COM To: David-Sarah Hopwood , tls@ietf.org Message-id: X-Mailer: Mulberry/4.0.8 (Mac OS X) References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B170D1D.7070401@jacaranda.org> Subject: Re: [TLS] Last Call: 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: Thu, 03 Dec 2009 04:44:55 -0000 --On December 3, 2009 0:58:05 +0000 David-Sarah Hopwood wrote: >> The issue with middleboxes was raised by others and is a straw man. >> There are government standards that have a fixed list of cipher suites >> and most clients can be configured to comply with those standards >> today. Given the TLS standards available at the time, a middlebox which >> enforced the presence of just those cipher suites and no others in the >> TLS handshake would reasonably be expected to be forwards compatible. > > That is not true. Any such middlebox would already have been broken > numerous times by browser implementors adding new cipher suites to the > list that they offer. I agree with Martin; this objection is based on a > completely implausible premise. The purpose of such a government standard (and any middlebox which enforced it) is to require all the browsers to be configured with a fixed cipher suite list of the approved cipher suites. As major browsers support such configuration (often via enterprise management tools), the default list of ciphers in a browser is irrelevant to the scenario. > (BTW, I don't think "straw man" is what you meant to say. > ) I meant . Or more precisely, I do not know if such boxes exist, but it is reasonable to postulate that they do and other people on the list have so postulated. >>> I consider this a defect in draft-ietf-tls-renegotiation-01. >>> There should be exactly **ONE** signaling mechanism for the initial >>> ClientHello on a connection so that extensions-tolerant but >>> extensions-free Servers will not be force to wade through lists >>> of extensions sent by clients. >> >> I'd be fine with one signaling mechanism as long as it's the mechanism >> that's been standardized since 2006 and backwards-compatible with >> correct implementations since 1999 (TLS 1.0). If we're misusing a >> cipher suite value as a protocol extensibility flag, an issue I'm >> willing to compromise on despite the lack of strong evidence it's >> necessary, we unfortunately need two signaling mechanisms: one that's >> standard that we know will work with modern correct implementations, and >> one a kludge that works with very old software, but might break >> good-faith modern implementations (like the middlebox straw man above). > > If the argument about middleboxes is simply wrong (which it is), then > this argument is also wrong. I reject that the middlebox argument is wrong. Even if it was, it is only one example of a bad consequence from unpredictable misuse of a standardize protocol field and thus would not invalidated the argument. > There is no need for two client->server > signalling mechanisms; it's unnecessary complexity. I have no problem with dropping the cipher suite value mechanism from the spec as there is no strong evidence it is necessary; that would result in a single symmetric negotiation mechanism; one that's using the predictable and standardized extensibility feature. I can live with the cipher suite value as a compromise as long as we're not _required_ to misuse that standardized protocol field in a way that implementers could not reasonably anticipate. - Chris From mickgray@au1.ibm.com Wed Dec 2 23:01: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 808D83A6778 for ; Wed, 2 Dec 2009 23:01:57 -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, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzxsjrANxUgm for ; Wed, 2 Dec 2009 23:01:56 -0800 (PST) Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by core3.amsl.com (Postfix) with ESMTP id 5A7993A688B for ; Wed, 2 Dec 2009 23:01:55 -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 nB3707WW030298 for ; Thu, 3 Dec 2009 18:00:07 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB36w9LG1347746 for ; Thu, 3 Dec 2009 17:58:09 +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 nB371jxT009512 for ; Thu, 3 Dec 2009 18:01:45 +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 nB371jog009509; Thu, 3 Dec 2009 18:01:45 +1100 In-Reply-To: <200912030225.nB32PHkW003916@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Thu, 3 Dec 2009 17:01:25 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 03/12/2009 18:08:39 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 07:01:57 -0000 Martin Rex wrote on 03/12/2009 12:25:17 PM: > Michael Gray wrote: > > > > I would go > > so far as to recommend that this method be used exclusively unless the > > Client in question is already sending extensions during ClientHello, in > > which case the Client should send the RI Extension instead of the > > CipherSuite as it is then clear that applying this security fix and sending > > the RI Extension does not result in a client behavior change. > > I'm sorry to disagree on this particular point. > (I've indicated this to Marsh previously, but not yet replied): > > If a client does not _always_ include the MCSV, it is making life > extra hard for extensions-tolerant but extensions-less SSLv3/TLSv1.0/TLSv1.1 > servers that do themselves _not_ need renegotation. > > An SSLv3 server that is already extensions-tolerant but does not > contain code to parse TLS extensions would have two options: > > 1) insist on clients to connect with extension-less ClientHellos > so that the necessary code changes to find the MCSV are tiny. > > 2) adopt generic TLS extensions code in order to find the > TLS extension RI among a lot of other TLS extensions. > > (1) is definitely much less work code-wise, but would amount to > a recommendation to effectively become extensions-intolerant. > > (2) is more work to implement (implementing 1 is still necessary, mind you) > and creates additional complexity for interop-testing > > > We do *NOT* need more than one signaling mechanism, so the use of > MCSV needs to be a MUST and the use of an empty TLS extension RI > on the initial ClientHello needs to be a SHOULD NOT. You make a good point and I believe such a proposition should be supported, however I think > " empty TLS extension RI on the initial ClientHello needs to be a SHOULD NOT" would be better if clarified such that the RI extension must not be sent on the initial ClientHello unless other extensions are being sent, as we do not want to see a Client protocol level behavior change in the initial connect. > The TLS extension RI can not be blindly asserted anyway, since > it needs to be filled with very specific data on renegotiation. > > The client should _ALWAYS_ include the MCSV, even when sending a > TLS extension RI that includes the verify_data from Client.Finished, > so that an updated SSLv3/TLSv1.0/TLSv1.1 server that is > extensions-tolerant but extension-less and does not implement > renegotiation can easily detect by presence of MCSV when a > updated client's renegotiation is proxied into the servers > initial handshake. > IMHO I do not see the requirement for a Server that would be updated to detect MSCV, but does not implement safe renegotiation. However I am not saying that such a requirement may not exist in constrained environments or for other reasons. - Mick From nelson@bolyard.me Wed Dec 2 23: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 296A03A69DB for ; Wed, 2 Dec 2009 23:30:48 -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 ilPstV5Lr22Q for ; Wed, 2 Dec 2009 23:30:47 -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 558763A67EE for ; Wed, 2 Dec 2009 23:30:47 -0800 (PST) Received: (qmail 11543 invoked from network); 3 Dec 2009 07:30:38 -0000 Received: from unknown (24.5.142.42) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 03 Dec 2009 07:30:38 -0000 Message-ID: <4B176914.3070803@bolyard.me> Date: Wed, 02 Dec 2009 23:30:28 -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: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B170D1D.7070401@jacaranda.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: 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: Thu, 03 Dec 2009 07:30:48 -0000 On 2009-12-02 20:44 PST, Chris Newman wrote: > --On December 3, 2009 0:58:05 +0000 David-Sarah Hopwood > wrote: >>> The issue with middleboxes was raised by others and is a straw man. >>> There are government standards that have a fixed list of cipher suites >>> and most clients can be configured to comply with those standards >>> today. Given the TLS standards available at the time, a middlebox which >>> enforced the presence of just those cipher suites and no others in the >>> TLS handshake would reasonably be expected to be forwards compatible. >> >> That is not true. Any such middlebox would already have been broken >> numerous times by browser implementors adding new cipher suites to the >> list that they offer. I agree with Martin; this objection is based on a >> completely implausible premise. > > The purpose of such a government standard (and any middlebox which enforced > it) is to require all the browsers to be configured with a fixed cipher > suite list of the approved cipher suites. As major browsers support such > configuration (often via enterprise management tools), the default list of > ciphers in a browser is irrelevant to the scenario. Speaking of government standards, the USG ruled back in the 1990s, even before RFC 2246 was published, that SSL 3.0 COULD NOT be FIPS compliant because of the ways in which MD5 and SHA1 were combined in SSL3's version of the PRF, but that TLS 1.0 could be because its PRF worked differently. They began to require TLS 1.0 compliance way back then. So, I'd expect that clients offering hellos with only version 0x0300 would already not be passing through their middle boxes. From SRS0=FGcl=HV=acm.org=bmoeller@srs.kundenserver.de Thu Dec 3 04:01: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 C3A053A68ED for ; Thu, 3 Dec 2009 04:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.179 X-Spam-Level: X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 Wi9hRbq5PzTk for ; Thu, 3 Dec 2009 04:01:57 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id A85A23A6992 for ; Thu, 3 Dec 2009 04:01:56 -0800 (PST) Received: from dhcp-172-28-209-248.zrh.corp.google.com ([74.125.57.33]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MP3gp-1N9rmq39Kp-006EyR; Thu, 03 Dec 2009 13:01:44 +0100 From: Bodo Moeller To: James Manger 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: Thu, 3 Dec 2009 13:01:43 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1/J4+SxcEfjZ74qf+lk1/t5W45/+m2tyT3jE+c xsf1Zki0IGqWfw/56YqKX2sKg40To0/6uW96YzN/koOgoNYVgu CGD4xCUjgpgV7x0g3OgcQ== Cc: "tls@ietf.org Working Group" Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 12:03:11 -0000 ]On Dec 1, 2009, at 2:43 PM, James Manger wrote: > I strongly support the consistent identity check in the Security > Considerations section of draft-ietf-tls-renegotiation-01. > > There may be some niche uses of TLS for which changing an identity > during renegotiation makes sense. That is adequately supported by > the last paragraph in the Security Considerations: "A TLS library > MAY provide a means for the application to allow identity and/or > server_name changes across renegotiations...". However, for 99.9...% > of TLS uses an identity changing during renegotiation will be > totally unexpected by the higher-layer application and can only > cause problems. > > A few people have argued that the consistent identity check is a > separate issue that should not be addressed now. I don't think that > is a fair characterisation. Even unpatched current TLS > implementations can unambiguously describe the authenticity and > confidentiality of every byte of application data. The bug only > occurs because apps don't expect a per-byte security context, but a > per-TLS-connection security context. Allowing the authenticated > identity to change per-byte does not solve this underlying mismatch > between what almost all apps expect and what TLS delivers. Keeping > identity consistent does narrow this mismatch. My point wasn't actually that I expect the peer's "identity" to change -- I expect that the peer's *identification information* may change in renegotiation handshakes, while each party should still be able to rely that it's continuing to talk to the *same* peer it has authenticated in the preceding handshake. Your point seems to be that particularly creative use of the protocol may violate the latter assumption. TLS has never meant to allow a new client or server application entity to enter the conversation when a renegotiation handshake takes place, but I agree that if this isn't sufficiently clear from the existing RFCs, then that's a concern addressing which is in the scope of the present ID. The Security Considerations section of draft-ietf-tls-renegotiation-01.txt has a fluffy layer of FUD around this core, however, which can easily get in the way -- and would impose rules that don't fit well into the overall design of TLS renegotiations. Here's a new proposal: "A TLS renegotiation handshake is a new handshake, including new cipher suite negotiation, and new Certificate messages where applicable. Accordingly, in the renegotiation handshake, clients and servers can use identifying information that is different from the identifying information used in the preceding handshake. (For example, one use of renegotiation is for TLS servers to initiate client authentication by sending a CertificateRequest message only when demanded by the application layer, in response to specific application-layer requests. The renegotiation handshake thus is expected to involve a client Certificate message when the preceding handshake did not. Furthermore, cipher suite selection during renegotiation will have to obey any restrictions imposed by CertificateRequest.certificate_types, and thus may require a different server Certificate message.) However, even when a TLS renegotiation handshake takes place, application data continues to be handled by the same application entity as before. TLS implementations MUST NOT use a change of Certificate information to indicate that subsequent application data will be in the responsibility of a different client or server application entity. That is, if a new or changed Certificate message appears in a renegotiation handshake and is successfully verified, it is understood that this is a change in identification information only and not a change in identity." Bodo From marsh@extendedsubset.com Thu Dec 3 05:54: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 B3C093A6A61 for ; Thu, 3 Dec 2009 05:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 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 9xmPFlRo6gNO for ; Thu, 3 Dec 2009 05:54: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 D6E9B3A684A for ; Thu, 3 Dec 2009 05:54: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 1NGC8E-000OgO-7f; Thu, 03 Dec 2009 13:54:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7183B603C; Thu, 3 Dec 2009 13:54: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/Ht0YZpNDIqVJh++Qx5SQ7v8WADwiwGJo= Message-ID: <4B17C2F9.9010802@extendedsubset.com> Date: Thu, 03 Dec 2009 07:54:01 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller 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 Working Group" , James Manger Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 13:54:15 -0000 Bodo Moeller wrote: > TLS has never meant to allow a new > client or server application entity to enter the conversation when a > renegotiation handshake takes place I disagree. The person(s) who added renegotiation clearly wanted to enable multiple "application entities" to run on the same port 443. These may be communicated over the same pool of active socket connections, as Nelson Bolyard of NSS (hier of the Netscape legacy implementation, twice removed) has described. Whether or not that was a wise design, or whether it was implemented perfectly is certainly debatable. We can all agree that certain implications of this design were under-documented. > Here's a new proposal: > > "[..] TLS implementations MUST NOT use a change of Certificate > information to indicate that subsequent application data will be in the > responsibility of a different client or server application entity. I don't support such wording. If someone wants to write a TLS application layer protocol that way, there's no good reason for the spec to prohibit it at this stage in the game. > That > is, if a new or changed Certificate message appears in a renegotiation > handshake and is successfully verified, it is understood that this is a > change in identification information only and not a change in identity." It might not even be a swap-out change, it could be additive or have other app-defined semantics. For example, a client or server application could renegotiate ten times and provide ten different certificates, then renegotiate to ephemeral Diffie-Hellman. The application protocol may be defined to treat subsequent data as being authenticated to any or all of the ten certificated identities. Another point is that TLS doesn't have to run over TCP. Imagine you need a way to securely convey authenticated data over a bare synchronous or asynchronous link (e.g. RS-232). TLS would be a natural choice, but if you restrict arbitrary certificate changes, you won't be able to use it continuously. You'll have to drop out of TLS altogether and start a new handshake, thus introducing unnecessary encryption and authentication gaps. - Marsh From stefan@aaa-sec.com Thu Dec 3 07:21: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 D2BD73A68CB for ; Thu, 3 Dec 2009 07:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 KkK0k5cgPZci for ; Thu, 3 Dec 2009 07:21:14 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id E317A3A62C1 for ; Thu, 3 Dec 2009 07:21:13 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id F17F02B7B12 for ; Thu, 3 Dec 2009 16:20:37 +0100 (CET) Received: (qmail 20741 invoked from network); 3 Dec 2009 15:20:31 -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 ; 3 Dec 2009 15:20:31 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 03 Dec 2009 16:20:30 +0100 From: Stefan Santesson To: , Michael Gray Message-ID: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Thread-Index: Acp0LCYYnAG8cl6tPU+le0aE4El61A== In-Reply-To: <200912030225.nB32PHkW003916@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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 15:21:14 -0000 On 09-12-03 3:25 AM, "Martin Rex" wrote: > We do *NOT* need more than one signaling mechanism, so the use of > MCSV needs to be a MUST and the use of an empty TLS extension RI > on the initial ClientHello needs to be a SHOULD NOT. > > The TLS extension RI can not be blindly asserted anyway, since > it needs to be filled with very specific data on renegotiation. > > The client should _ALWAYS_ include the MCSV, even when sending a > TLS extension RI that includes the verify_data from Client.Finished, > so that an updated SSLv3/TLSv1.0/TLSv1.1 server that is > extensions-tolerant but extension-less and does not implement > renegotiation can easily detect by presence of MCSV when a > updated client's renegotiation is proxied into the servers > initial handshake. +1 From dean@av8.com Thu Dec 3 08:24: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 5FFD33A676A for ; Thu, 3 Dec 2009 08:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 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 X1ZFcVlo-Ac8 for ; Thu, 3 Dec 2009 08:24:08 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 66E463A672F for ; Thu, 3 Dec 2009 08:24:07 -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 nB3GNtRJ015739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Dec 2009 11:23:55 -0500 Date: Thu, 3 Dec 2009 11:23:54 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Richard Stallman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org, tglassey@earthlink.net, 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 List-Id: "This is the mailing list 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, 03 Dec 2009 16:24:09 -0000 On Wed, 2 Dec 2009, Richard Stallman wrote: > Seems to me that, in the context of asking parties to self-declare their > "IP", it's better to error on the side of overly broad terminology. > > I think you may not appreciate how different these laws are. There is > no way copyrights can restrict the use of a normal internet standard. User interface copyrights could have done so. We defeated UI copyrights, but people can continue to invent new ways of using old laws. It would be better to know about such novel claims sooner rather than later > (Someone might have a copyright on text you want to incorporate into > the text of the standard, but that is a different kind of issue. > Also, the IETF presumably knows who contributed that text, so there > is no need to ask the public "Did any of this text come from you?") > > Someone somewhere is thinking he has a trademark on the first four > octets of a protocol message > > Trademark laws concerns the way products are packaged and advertised. It might be possible to trademark an IP address block. If IP blocks are hijacked, and used to send spam, the reputation of the rightful owner or delegated user of the block is harmed in much the same way as false labeling of products and services. I can't say whether this is a good argument, but it appears that people in some quarters are thinking about it. Trademarks could affect a standard if the standard incorporates the trademark in the text. Sun tried to trademark the phrase "Open Systems" once. (The OSF caught the notice and successfully objected). > Basically, only patent law can prohibit use of a standard. We hope. But how do we ask (essentiall) if someone is trying to invent some new way of using these laws (as they did with UI copyrights)? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494 From SRS0=FGcl=HV=acm.org=bmoeller@srs.kundenserver.de Thu Dec 3 08: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 85C6C3A68C3 for ; Thu, 3 Dec 2009 08:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 myZrdrLq-zRS for ; Thu, 3 Dec 2009 08:31:12 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id CBFD33A682B for ; Thu, 3 Dec 2009 08:31:06 -0800 (PST) Received: from dhcp-172-28-209-248.zrh.corp.google.com ([74.125.57.33]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MTKyZ-1Neb531mVj-00SHOe; Thu, 03 Dec 2009 17:30:52 +0100 From: Bodo Moeller To: Marsh Ray In-Reply-To: <4B17C2F9.9010802@extendedsubset.com> References: <4B17C2F9.9010802@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: Thu, 3 Dec 2009 17:30:50 +0100 X-Mailer: Apple Mail (2.936) X-Provags-ID: V01U2FsdGVkX1+NHzkxRLuhVQSfYXPtTOcJIdc1/tnZKiyWQFi nh1Ea3D3ZuD2TiSazAb7HPddxZtrP/xJ0GCnZtzaQVKX7INhJ2 Sk5ozD0LheECACaDHFnfw== Cc: "tls@ietf.org Working Group" , James Manger Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 16:31:13 -0000 On Dec 3, 2009, at 2:54 PM, Marsh Ray wrote: > Bodo Moeller wrote: >> TLS has never meant to allow a new >> client or server application entity to enter the conversation when a >> renegotiation handshake takes place > I disagree. The person(s) who added renegotiation clearly wanted to > enable multiple "application entities" to run on the same port 443. I don't think this is true, and certainly not clear -- for example, see: http://www.imc.org/ietf-tls/mail-archive/msg01294.html ("This is how cipherSuites are renegotiated" - Eric Rescorla, 1998) http://www.imc.org/ietf-tls/mail-archive/msg01295.html ("Hello requests can also be used to cause re-keying ... like, if you sent more data than you think you should send with a given set of keys" - David Brownell, 1998) -- and do you remember http://web.archive.org/web/19990422033121/http://developer.netscape.com/tech/security/stepup/overview.html? Also, ever since the SSL 2.0 protocol specification, the documents have said that the client is one application entity ("the application entity that initiates a connection"), and the server is one application entity ("the application entity that responds to requests for connections from clients"). If you look at the SSL 3.0 specification, renegotiation takes place between "the" client and "the" server. A scenario where one SSL-level client does multiplexing on behalf of multiple application-level clients, or one SSL-level server does multiplexing on behalf of multiple application-level servers, just wouldn't be covered by this. > These may be communicated over the same pool of active socket > connections, as Nelson Bolyard of NSS (hier of the Netscape legacy > implementation, twice removed) has described. Where has he described this? (Sorry -- I've tried to find something using various keywords, but to no avail.) >> Here's a new proposal: >> >> "[..] TLS implementations MUST NOT use a change of Certificate >> information to indicate that subsequent application data will be in >> the >> responsibility of a different client or server application entity. > I don't support such wording. If someone wants to write a TLS > application layer protocol that way, there's no good reason for the > spec > to prohibit it at this stage in the game. As explained above, I don't think this would be within what the SSL/ TLS base specification allows -- of course you can still decide do it anyway, as a custom modification to the standard protocol. Well, I guess we could cater for that, by again saying "by default": "A TLS renegotiation handshake is a new handshake, including new cipher suite negotiation, and new Certificate messages where applicable. Accordingly, in the renegotiation handshake, clients and servers can use identifying information that is different from the identifying information used in the preceding handshake. (For example, one use of renegotiation is for TLS servers to initiate client authentication by sending a CertificateRequest message only when demanded by the application layer, in response to specific application-layer requests. The renegotiation handshake thus is expected to involve a client Certificate message when the preceding handshake did not. Furthermore, cipher suite selection during renegotiation will have to obey any restrictions imposed by CertificateRequest.certificate_types, and thus may require a different server Certificate message.) However, even when a TLS renegotiation handshake takes place, application data normally continues to be handled by the same application entity as before. TLS implementations by default MUST NOT use a change of Certificate information to indicate that subsequent application data will be in the responsibility of a different client or server application entity. That is, if a new or changed Certificate message appears in a renegotiation handshake and is successfully verified, it is understood that this is a change in identification information only and not a change in identity. Still any party relying on peer authentication remains responsible for verifying authentication information even on renegotiation handshakes. Some application protocols might have to use the TLS protocol in a nonstandard setting where a single connection is used with renegotiation to multiplex for multiple application entities. The design of such application protocols requires special care to ensure that application data cannot be processed or sent in an inappropriate context, taking into account that the TLS protocol generally allows application data to be interleaved with renegotiation handshakes, and that the record layer cannot generally be expected to preserve application message boundaries, and may send application data at lower priority than other content types. Thus, such application protocols will have to specify their special requirements on TLS implementations. TLS implementations to be used for such applications may require additional API facilities." Bodo From marsh@extendedsubset.com Thu Dec 3 10:54: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 5BD5628C188 for ; Thu, 3 Dec 2009 10:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.263 X-Spam-Level: X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_00=-2.599, FRT_ESTABLISH2=2.492] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M0bk4liu3bt for ; Thu, 3 Dec 2009 10:54:54 -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 E495628C190 for ; Thu, 3 Dec 2009 10:54:53 -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 1NGGp9-0004lY-SD; Thu, 03 Dec 2009 18:54:44 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A7A60603C; Thu, 3 Dec 2009 18:54: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: U2FsdGVkX19jjTYXwP+jtqmZx4weQRi1+Jl43O66Psc= Message-ID: <4B18096E.20805@extendedsubset.com> Date: Thu, 03 Dec 2009 12:54:38 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bodo Moeller References: <4B17C2F9.9010802@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 Cc: "tls@ietf.org Working Group" , James Manger Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 18:54:55 -0000 Bodo Moeller wrote: > On Dec 3, 2009, at 2:54 PM, Marsh Ray wrote: >> Bodo Moeller wrote: > >>> TLS has never meant to allow a new >>> client or server application entity to enter the conversation when a >>> renegotiation handshake takes place Granted, they didn't expect it to be MitM-able. >> I disagree. The person(s) who added renegotiation clearly wanted to >> enable multiple "application entities" to run on the same port 443. > > I don't think this is true, and certainly not clear -- for example, see: Here's what I've been reading, which goes back earlier: http://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft302.txt INTERNET-DRAFT SSL 3.0 November 18, 1996 "The client can also send a client hello in response to a hello request or on its own initiative in order to renegotiate the security parameters in an existing connection." What exactly are these "security parameters" the authors are referring to? Well the document doesn't define the term exactly, but uses it again with more context: "Sessions define a set of cryptographic security parameters, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection." "The cryptographic parameters of the session state are produced by the SSL Handshake Protocol, which operates on top of the SSL Record Layer. When a SSL client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets." It certainly sounds to me like the spec intended to allow anything that was valid in an initial negotiation to be valid in a renegotiation. Interestingly, variations on the word "renegotiate" only appear three times. The Hello Request message does not use the term, instead it talks about a new "negotiation". To me, this reinforces the idea that the authors of the SSLv3 spec intended renegotiation to be fully equivalent to a new handshake. > Also, ever since the SSL 2.0 protocol specification, the documents have > said that the client is one application entity ("the application entity > that initiates a connection"), and the server is one application entity > ("the application entity that responds to requests for connections from > clients"). If you look at the SSL 3.0 specification, renegotiation > takes place between "the" client and "the" server. A scenario where one > SSL-level client does multiplexing on behalf of multiple > application-level clients, or one SSL-level server does multiplexing on > behalf of multiple application-level servers, just wouldn't be covered > by this. The 3.0 spec uses the term "application entity" in two places" "client The application entity that initiates a connection to a server." "server The server is the application entity that responds to requests for connections from clients. The server is passive, waiting for requests from clients." These definitions were inherited verbatim from the SSLv2 spec, so I don't think much weight was placed on the term "application entity". In any case, it just refers to the initial connection process which esatablishes the roles of client and server. But I believe one of the initial motivations of renegotiation was to enable multiple CGI-type applications to run on the same server. These could certainly have different authentication requirements, and renegotiation was added (at least in part) to provide for dynamic (re)authentication. >> These may be communicated over the same pool of active socket >> connections, as Nelson Bolyard of NSS (hier of the Netscape legacy >> implementation, twice removed) has described. > > Where has he described this? (Sorry -- I've tried to find something > using various keywords, but to no avail.) Sorry, I think it may have been a private mail. Nelson, would you mind posting that? I refer to it often. I have it in my box dated 10/16/2009 6:27 PM Message-ID: <4AD90164.6080304@bolyard.me>. I'm sure he wouldn't mind me sharing this tidbit: "It is also possible that, in response to a client hello request, the client will send a client hello bearing a session ID that is not empty and is NOT the session ID of the session presently in use on that connection. This can happen when the client has multiple connections going in parallel between the same client identity session cache and the same remote server." Now I don't perfectly understand how Mozilla handles its "client identity session cache" (I suspect no one does), but it sounds plausible to me that renegotiation with resumption could, in theory, switch between differing client certs over the same connection. This might be fun to test, actually. >> If someone wants to write a TLS >> application layer protocol that way, there's no good reason for the spec >> to prohibit it at this stage in the game. > > As explained above, I don't think this would be within what the SSL/TLS > base specification allows -- of course you can still decide do it > anyway, as a custom modification to the standard protocol. What wording in what spec prohibits it? Everything I read is consistently "anything goes" in renegotiation, just like an initial handshake. OpenSSL, for example, had to add new code in order to disable renegotiation: there was previously zero special-case handling for it. > Well, I guess we could cater for that, by again saying "by default": This does not appeal to me in a spec. It seems like it would be saying "here's how you have to do it ... except if you don't want to, then just do whatever". > "A TLS renegotiation handshake is a new handshake, including new cipher > suite negotiation, and new Certificate messages where applicable. > Accordingly, in the renegotiation handshake, clients and servers can use > identifying information that is different from the identifying > information used in the preceding handshake. (For example, one use of > renegotiation is for TLS servers to initiate client authentication by > sending a CertificateRequest message only when demanded by the > application layer, in response to specific application-layer requests. > The renegotiation handshake thus is expected to involve a client > Certificate message when the preceding handshake did not. Furthermore, > cipher suite selection during renegotiation will have to obey any > restrictions imposed by CertificateRequest.certificate_types, and thus > may require a different server Certificate message.) > > However, even when a TLS renegotiation handshake takes place, > application data normally continues to be handled by the same > application entity as before. TLS implementations by default > MUST NOT use a change of Certificate information to indicate that > subsequent application data will be in the responsibility of a different > client or server application entity. That is, if a new or changed > Certificate message appears in a renegotiation handshake and is > successfully verified, it is understood that this is a change in > identification information only and not a change in identity. > Still any party relying on peer authentication remains responsible > for verifying authentication information even on renegotiation > handshakes. > > Some application protocols might have to use the TLS protocol in a > nonstandard setting where a single connection is used with renegotiation > to multiplex for multiple application entities. The design of such > application protocols requires special care to ensure that application > data cannot be processed or sent in an inappropriate context, taking > into account that the TLS protocol generally allows application data to > be interleaved with renegotiation handshakes, and that the record layer > cannot generally be expected to preserve application message boundaries, > and may send application data at lower priority than other content > types. Thus, such application protocols will have to specify their > special requirements on TLS implementations. TLS implementations to be > used for such applications may require additional API facilities." This is outside the scope of the wire protocol and on new territory attempting to specifying the library API. Not saying that's necessarily bad, but more than likely it will simply be ignored. What I think would be far more useful is a practical treatment of the best practices and possible pitfalls for implementing and using typical library APIs. Some of this is in Appendix D. Implementation Notes, but it could be given its own section with advice like: * Although most TLS libraries will properly validate a cert, the application code is usually still responsible for checking that the cert identifies the intended host. This is because the exact method to be used depends upon the application protocol in use. This check MUST be done at the earliest opportunity during the handshake process. This usually necessitates an application-supplied callback function be registered with the TLS implementation. Returning a failure code from the callback MUST terminate the handshake. * The TLS protocol allows application data to be interleaved within rengotiation handshake messages. Sometimes this is desired, but may require extra care. The application-supplied callback and TLS library normally SHOULD discard any buffered plaintext at the point of renegotiation. It is recommended that TLS libraries default to neither sending nor accepting of application data during a renegotiation (between the Hello and the Finished handshake messages). and so on... - Marsh From marsh@extendedsubset.com Thu Dec 3 11: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 516AE28C168 for ; Thu, 3 Dec 2009 11:31:36 -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 8kPMgKqjt5uP for ; Thu, 3 Dec 2009 11:31: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 9043428C1A3 for ; Thu, 3 Dec 2009 11:31: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 1NGHOg-000MEh-Ia; Thu, 03 Dec 2009 19:31:26 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 65304603C; Thu, 3 Dec 2009 19:31:24 +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+nlSEW2GRAoHyKjwhu3FO+qIxNVWWm0Ys= Message-ID: <4B181209.5090507@extendedsubset.com> Date: Thu, 03 Dec 2009 13:31:21 -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: <200912030225.nB32PHkW003916@fs4113.wdf.sap.corp> In-Reply-To: <200912030225.nB32PHkW003916@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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 19:31:36 -0000 I'm thinking this is the only big sticking point left for draft-ietf-tls-renegotiation? Martin Rex wrote: > > We do *NOT* need more than one signaling mechanism, so the use of > MCSV needs to be a MUST and the use of an empty TLS extension RI > on the initial ClientHello needs to be a SHOULD NOT. I for one would like to see the day (say in TLS 1.7) when we no longer need to send the MCSV on every Client Hello. It is, after all, a hack. In order for this to ever be possible, we need servers from the first implementation of this patch to accept and work with either the extension or the MCSV. The MCSV was a concession to those who needed, on occasion, to not send any extensions. It sounds like the great majority of servers do not break when sent extensions. Modern browsers are sending the SNI extension, no need for the hack there. Let them use the MCSV only for the (sigh) fall-back logic. - Marsh From Tolga.Acar@microsoft.com Thu Dec 3 11:47: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 155403A6907 for ; Thu, 3 Dec 2009 11:47:02 -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 he9pQaZqt7XY for ; Thu, 3 Dec 2009 11:47:01 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by core3.amsl.com (Postfix) with ESMTP id 229493A68C2 for ; Thu, 3 Dec 2009 11:47:00 -0800 (PST) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.0.639.21; Thu, 3 Dec 2009 11:46:52 -0800 Received: from df-bhd-05.exchange.corp.microsoft.com (157.54.87.84) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.0.682.1; Thu, 3 Dec 2009 11:46:49 -0800 Received: from DF-POINTER-MSG.exchange.corp.microsoft.com ([157.54.62.139]) by df-bhd-05.exchange.corp.microsoft.com ([157.54.87.84]) with mapi; Thu, 3 Dec 2009 11:46:20 -0800 From: Tolga Acar To: Kyle Hamilton , Eric Rescorla Date: Thu, 3 Dec 2009 11:46:20 -0800 Thread-Topic: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS Thread-Index: Acpx67Ybf+aOSCEYTpOUwLJVYkSZSgCY4aBA Message-ID: References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> <20091130182931.39B596C3EB8@kilo.networkresonance.com> <6b9359640911301031o435c8ae9w93ffffb8ac04353a@mail.gmail.com> In-Reply-To: <6b9359640911301031o435c8ae9w93ffffb8ac04353a@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 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: Thu, 03 Dec 2009 19:47:02 -0000 SSBsb29rZWQgYXQgRFRMUyBhbmQgaXQgZG9lc24ndCBzZWVtIGxpa2UgaXQgaXMgdnVsbmVyYWJs ZSBhcyBUTFMgaXMuDQpUaGUgInVpbnQxNiBlcG9jaCIgYW5kICJ1aW50NDggc2VxdWVuY2VfbnVt YmVyIiBpbiB0aGUgcmVjb3JkIGhlYWRlciBhcmUgaW5wdXQgdG8gdGhlIE1BQyBhbmQgYXJlIHZh bGlkYXRlZCBwZXIgUkZDNDM0NyBTZWN0aW9uIDQuMS4yLjEuIEl0IHNlZW1zIHRvIG1lIHRoYXQg YSBNaVRNIHdvdWxkIG5vdCBoYXZlIGEgIG1hdGNoaW5nIGVwb2NoK3NlcXVlbmNlIG51bWJlciwg dGhlIE1pVE0gY2FuJ3QgY2hhbmdlIHRoZW0gKG9rLCBtYXkgY2hhbmdlLCBidXQgTUFDIHdvdWxk IG5vdCB2YWxpZGF0ZSksIGFuZCBpdCB0YWtlcyAyXjQ4IGZvciB0aGVtIHRvIHJvbGwgb3Zlci4g U28sIHNob3J0IG9mIDJeNDggYml0IHJvbGxvdmVyIChhbmQsIGRvbid0IGZvcmdldCB0aGUgbWVz c2FnZSBzZXF1ZW5jZSBudW1iZXIgPHVpbnQxNj4gaW5zaWRlIHRoZSByZWNvcmQpLCBJIGRvbid0 IHNlZSBob3cgTWlUTSB3b3VsZCB3b3JrIGluIERUTFMuDQoNCkhvd2V2ZXIsIGluIHRoZSBsYXN0 IHBhcmFncmFwaCBvZiB0aGUgc2FtZSBzZWN0aW9uLCBpdCBzYXlzICJEVExTIGltcGxlbWVudGF0 aW9ucyBTSE9VTEQgc2lsZW50bHkgZGlzY2FyZCBkYXRhIHdpdGggYmFkIE1BQ3MiLiBJZiBhbiBp bXBsZW1lbnRhdGlvbiB3ZXJlIHRvIGlnbm9yZSBiYWQgTUFDcywgdGhpbmdzIHdvdWxkIGdvIGJh ZCBhbmQgTWlUTSB3b3VsZCBiZSBhcHBsaWNhYmxlLiBJIHN1Z2dlc3QgU0hPVUxEIGJlIGNoYW5n ZWQgdG8gTVVTVDsgb3IgcGVvcGxlIG11c3QgZXhwZWN0IHRoYXQgaW1wbGVtZW50YXRpb25zIHdv dWxkIGJhcmYgb24gbWFkIE1BQ3MuIA0KDQotIFRvbGdhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiB0bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgS3lsZSBIYW1pbHRvbg0KU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAzMCwgMjAwOSAxMDozMiBBTQ0KVG86IEVyaWMgUmVzY29ybGENCkNjOiB0bHNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbVExTXSBkcmFmdC1pZXRmLXRscy1yZW5lZ290aWF0aW9uLTAxLnR4dCBh bmQgRFRMUw0KDQpJIHdvdWxkIHN1cHBvcnQgcmFuZG9taXppbmcgdGhlIGVwb2NoIGNvdW50ZXIg aW4gRFRMUywgZ2l2aW5nIGEgMToyXjE2IGNoYW5jZSBvZiBnZXR0aW5nIGl0IHJpZ2h0IGluIGEg c2luZ2xlIGF0dGVtcHQuICAoVGhpcyBmb2xsb3dzIG15IG9ic2VydmF0aW9uIHRoYXQgdGhlIGhh c2ggc2F2ZWQgZnJvbSB0aGUgbGFzdCBGaW5pc2hlZCBtZXNzYWdlIGlzIGVzc2VudGlhbGx5IHRo ZSBzYW1lIGFzIGEgbmFtZWQgZXBvY2guKQ0KDQotS3lsZSBIDQoNCk9uIE1vbiwgTm92IDMwLCAy MDA5IGF0IDEwOjI5IEFNLCBFcmljIFJlc2NvcmxhIDxla3JAbmV0d29ya3Jlc29uYW5jZS5jb20+ IHdyb3RlOg0KPiBBdCBNb24sIDMwIE5vdiAyMDA5IDEyOjA2OjAyIC0wNjAwLA0KPiBNYXJzaCBS YXkgd3JvdGU6DQo+Pg0KPj4gTWljaGFlbCBUw7x4ZW4gd3JvdGU6DQo+PiA+DQo+PiA+IElmIEkn bSBub3Qgd3JvbmcsIHRoZW4gdGhlIGF0dGFjayB3aGljaCB3b3JrcyBhZ2FpbnN0IFRMUyBkb2Vz IG5vdCANCj4+ID4gd29yayBhZ2FpbnN0IERUTFMsIHNpbmNlIERUTFMgaGFzIGFuIGVwb2NoIGNv dW50ZXIuDQo+PiA+DQo+PiA+IElmIGEgY2xpZW50IHRyaWVzIHRvIGVzdGFibGlzaCBhIERUTFMg Y29ubmVjdGlvbiBhbmQgYSBNSVRNIA0KPj4gPiBpbnRlcmNlcHRzIGl0LCBlc3RhYmxpc2hlcyBp dHNlbGYgYSBEVExTIGNvbm5lY3Rpb24sIHRoZSBlcG9jaCBpcyANCj4+ID4gMS4gVGhlcmUgd2ls bCBiZSBhIGZpbmFsIG1pc21hdGNoIGluIHRoZSBlcG9jaCBhbmQgdGhlIHBhY2tldHMgd2lsbCAN Cj4+ID4gYmUgZGlzY2FyZGVkLiBXaGVuIHVzaW5nIHRoZSBSSSBleHRlbnNpb24gb25lIGNvdWxk IGVuZm9yY2UgdGhlIHNlbmRpbmcgb2YgdGhlIGFsZXJ0IG1lc3NhZ2UuDQo+PiA+IEJ1dCB0aGUg b3JpZ2luYWwgYXR0YWNrIGlzIG5vdCBwb3NzaWJsZSwgSSB0aGluay4NCj4+ID4NCj4+ID4gSXMg bXkgYW5hbHlzaXMgY29ycmVjdCBvciBhbSBJIG92ZXJsb29raW5nIHNvbWV0aGluZz8NCj4+DQo+ PiBDYW4gTWl0TSBkbyB0aGUgc2FtZSBudW1iZXIgb2YgcmVuZWdvdGl0YXRpb25zIGFzIGhlIGRv ZXMgd2l0aCB0aGUgDQo+PiBzZXJ2ZXIgYmVmb3JlIHNwbGljaW5nIGhpbT8NCj4NCj4gTmFnZW5k cmF5IGFuZCBJIGhhZCB0aGlzIGNvbnZlcnNhdGlvbiBsYXN0IHdlZWsuIFdoaWxlIEkgaGF2ZW4n dCBkb25lIA0KPiBhIGNvbXBsZXRlIGFuYWx5c2lzLCBteSBpbnR1aXRpb24gaXMgdGhhdCBEVExT IGlzIG1vcmUgcmVzaXN0YW50IChmb3IgDQo+IHRoZSByZWFzb24geW91IGluZGljYXRlKSBidXQg bm90IDEwMCUgcmVzaXN0YW50LiDCoEFub3RoZXIgY29uY2VybiANCj4gd291bGQgYmUgZXBvY2gg cm9sbG92ZXI6IHdoYXQgaWYgeW91IGRvIDY1NTM2ICg2NTUzNT8tLXRvbyBsYXp5IHRvDQo+IGNh bGN1bGF0ZSkgaGFuZHNoYWtlcyB3aXRoIHRoZSBzZXJ2ZXIgYW5kIGZvcmNlIHRoZSBlcG9jaCBi YWNrIHRvIDA/DQo+DQo+IFNvLCBwcm9iYWJseSBiZXR0ZXIgdG8gdXNlIFJJIHdpdGggRFRMUyBh cyB3ZWxsLg0KPg0KPiAtRWtyDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExTQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From marsh@extendedsubset.com Thu Dec 3 12:02: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 217AA28C1B9 for ; Thu, 3 Dec 2009 12:02: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.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 UQhsejRGAuxd for ; Thu, 3 Dec 2009 12:02:06 -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 66CDD28C180 for ; Thu, 3 Dec 2009 12:01: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 1NGHrt-000Bwd-KS; Thu, 03 Dec 2009 20:01:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 01400603C; Thu, 3 Dec 2009 20:01: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: U2FsdGVkX19OGNxOgbi8/uCZWOr5/9P2ADKV04Ou9oo= Message-ID: <4B18191C.5080607@extendedsubset.com> Date: Thu, 03 Dec 2009 14:01:32 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tolga Acar References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> <20091130182931.39B596C3EB8@kilo.networkresonance.com> <6b9359640911301031o435c8ae9w93ffffb8ac04353a@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kyle Hamilton , "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: Thu, 03 Dec 2009 20:02:08 -0000 Tolga Acar wrote: > I looked at DTLS and it doesn't seem like it is vulnerable as TLS is. > The "uint16 epoch" and "uint48 sequence_number" in the record header > are input to the MAC and are validated per RFC4347 Section 4.1.2.1. > It seems to me that a MiTM would not have a matching epoch+sequence > number, the MiTM can't change them (ok, may change, but MAC would not > validate), and it takes 2^48 for them to roll over. Couldn't he possibly 'prep' the client by triggering the exchange of the appropriate number of dummy records before splicing him into the server connection? Is there something about the DTLS sequence_number that makes it more resilient than the TLS record sequence number? - Marsh From mrex@sap.com Thu Dec 3 12: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 6D5183A6784 for ; Thu, 3 Dec 2009 12:23:31 -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 DMdSwC5ExSsZ for ; Thu, 3 Dec 2009 12:23: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 5382F3A63C9 for ; Thu, 3 Dec 2009 12:23:30 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB3KNJbL008127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 21:23:19 +0100 (MET) From: Martin Rex Message-Id: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 3 Dec 2009 21:23:18 +0100 (MET) In-Reply-To: <4B181209.5090507@extendedsubset.com> from "Marsh Ray" at Dec 3, 9 01:31: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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 20:23:31 -0000 Marsh Ray wrote: > > > I'm thinking this is the only big sticking point left for > draft-ietf-tls-renegotiation? > > > Martin Rex wrote: > > > > We do *NOT* need more than one signaling mechanism, so the use of > > MCSV needs to be a MUST and the use of an empty TLS extension RI > > on the initial ClientHello needs to be a SHOULD NOT. > > I for one would like to see the day (say in TLS 1.7) when we no longer > need to send the MCSV on every Client Hello. It is, after all, a hack. > > In order for this to ever be possible, we need servers from the first > implementation of this patch to accept and work with either the > extension or the MCSV. > > The MCSV was a concession to those who needed, on occasion, to not send > any extensions. It sounds like the great majority of servers do not > break when sent extensions. > > Modern browsers are sending the SNI extension, no need for the hack > there. Let them use the MCSV only for the (sigh) fall-back logic. Do you really want to punish _ALL_ the extensions-tolerant Servers that do not implement TLS extensions so far for being extensions-tolerant? Sounds like a pretty bad idea to me. If you don't require the MCSV on all ClientHellos, then all extension-tolerant servers must implement TLS extensions in order to wade through the extensions sent by clients in order to find an empty TLS extension RI or one that contains verify_data from a Client.Finished message. That applies to all implementations of SSLv3,TLSv1.0,TLSv1.1 servers which do _not_ need renegotiation. Extensions-intolerant are going to benefit most when they remain extensions-intolerant, becaus then they will have to look only for MCSV, which is minimal code. I'm sorry, but I think such an approach would be sending an extremely wrong message! -Martin From ekr@networkresonance.com Thu Dec 3 12: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 22B5128C1BD for ; Thu, 3 Dec 2009 12:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[AWL=0.100, 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, 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 WKzdqBnbbSMH for ; Thu, 3 Dec 2009 12:43:51 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 7151128C1AD for ; Thu, 3 Dec 2009 12:43:51 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 463F86C4A7E; Thu, 3 Dec 2009 12:45:05 -0800 (PST) Date: Thu, 03 Dec 2009 12:45:04 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B18191C.5080607@extendedsubset.com> References: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> <20091130182931.39B596C3EB8@kilo.networkresonance.com> <6b9359640911301031o435c8ae9w93ffffb8ac04353a@mail.gmail.com> <4B18191C.5080607@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: <20091203204505.463F86C4A7E@kilo.networkresonance.com> Cc: Tolga Acar , Kyle Hamilton , "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: Thu, 03 Dec 2009 20:43:52 -0000 At Thu, 03 Dec 2009 14:01:32 -0600, Marsh Ray wrote: > > Tolga Acar wrote: > > I looked at DTLS and it doesn't seem like it is vulnerable as TLS is. > > The "uint16 epoch" and "uint48 sequence_number" in the record header > > are input to the MAC and are validated per RFC4347 Section 4.1.2.1. > > It seems to me that a MiTM would not have a matching epoch+sequence > > number, the MiTM can't change them (ok, may change, but MAC would not > > validate), and it takes 2^48 for them to roll over. > > Couldn't he possibly 'prep' the client by triggering the exchange of the > appropriate number of dummy records before splicing him into the server > connection? > > Is there something about the DTLS sequence_number that makes it more > resilient than the TLS record sequence number? The sequence number still zeros at every handshake. AFAIK, the only protection is the epoch, which, as discussed, is potentially manipulable. -Ekr From marsh@extendedsubset.com Thu Dec 3 12:52: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 3273D28C1CF for ; Thu, 3 Dec 2009 12:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtVe4I+skgOv for ; Thu, 3 Dec 2009 12:52:23 -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 3C73928C1CA for ; Thu, 3 Dec 2009 12:52:23 -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 1NGIer-0008d6-2I; Thu, 03 Dec 2009 20:52:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 96EA7603C; Thu, 3 Dec 2009 20:52: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: U2FsdGVkX187r3TVzyL93eMU00IonKTOm5wulhWgiWo= Message-ID: <4B1824F7.709@extendedsubset.com> Date: Thu, 03 Dec 2009 14:52:07 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> In-Reply-To: <200912032023.nB3KNIS2008868@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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 20:52:24 -0000 Martin Rex wrote: > Marsh Ray wrote: >> >> I for one would like to see the day (say in TLS 1.7) when we no longer >> need to send the MCSV on every Client Hello. It is, after all, a hack. >> >> In order for this to ever be possible, we need servers from the first >> implementation of this patch to accept and work with either the >> extension or the MCSV. >> >> The MCSV was a concession to those who needed, on occasion, to not send >> any extensions. It sounds like the great majority of servers do not >> break when sent extensions. >> >> Modern browsers are sending the SNI extension, no need for the hack >> there. Let them use the MCSV only for the (sigh) fall-back logic. > > > Do you really want to punish _ALL_ the extensions-tolerant Servers > that do not implement TLS extensions so far for being > extensions-tolerant? Sounds like a pretty bad idea to me. What are you talking about? > If you don't require the MCSV on all ClientHellos, then all > extension-tolerant servers must implement TLS extensions in order > to wade through the extensions sent by clients Yes, they would need to parse the extensions rather than ignore them. It's a 4 line 'for' loop, big deal. They don't have to add full support for generic extension handling to their API to do this. > in order to find > an empty TLS extension RI or one that contains verify_data > from a Client.Finished message. There's no other way to supply verify_data. > That applies to all implementations > of SSLv3,TLSv1.0,TLSv1.1 servers which do _not_ need renegotiation. I am not aware of any TLS implementations that do not support renegotiation (although I'm sure they exist). > Extensions-intolerant are going to benefit most when they remain > extensions-intolerant, becaus then they will have to look only > for MCSV, which is minimal code. > > > I'm sorry, but I think such an approach would be sending > an extremely wrong message! Sorry, I'm not seeing the big message here. The fix we have with requires an extension. Implementations will have to handle it, but it's pretty minimal. It doesn't have to be a lot of code, but even an implementation that doesn't "do renegotiation" needs to look for the RI response in the Server Hello. The MCSV is just a little hack as a concession to the fact that some clients can't always send extensions because some broken servers in the wild give slow failures when sent extensions. It doesn't get you out of being able to properly walk a short list of extensions. - Marsh From frantz@pwpconsult.com Thu Dec 3 13:06: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 6D30928C198 for ; Thu, 3 Dec 2009 13:06:57 -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 fCPEzf+IpGnS for ; Thu, 3 Dec 2009 13:06:56 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 010C83A62C1 for ; Thu, 3 Dec 2009 13:06:55 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NGIsx-0003mr-8S for tls@ietf.org; Thu, 03 Dec 2009 16:06:47 -0500 Date: Thu, 3 Dec 2009 13:07:25 -0800 From: Bill Frantz To: "tls@ietf.org Working Group" X-Priority: 3 In-Reply-To: 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec793a88140731f6a7bcd266708f9bb635e2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 21:06:57 -0000 Perhaps we might be able to get a bit more clarity on this issue if we consider the authorizations that the application layer may make based on the identification provided by TLS and by additional identification/authorization information in the data stream. It seems to me that we are trying to fix a bug in exhibited by some systems where some data is received before the information needed to perform an authorization (AInfo) is sent by the sender. When this data is generated by a sender with different goals than the entity which sends the AIinfo, and the application treats is as if it was sent by the same entity the bug occurs. At the same time, we want to permit the renegotiations and data stream to increase the authorizations associated with the channel[1]. Some people seem to want to allow losing the previous authorizations, and presumably the associated requests, when new identifications are received. If this logic were universally implemented, we wouldn't have a bug to fix. Since I like to have concrete examples to test my reasoning against, I offe= r two: HTTPS: The MITM offers it's own GET/POST line, and eats the client's GET/POST line with an unterminated header. The client's cookies (AInfo) are applied to the MITM's GET/POST. Waterken: "Each invocation is sent as an HTTP request: either a POST for an update, or a GET for a query. The request URL fully identifies the invocation target and any arguments are carried in the request body, encoded in JSON."[2] The MITM can substitute his own GET/PUT line as with HTTPS, allowing his own resource to gain access to the argument authorizations carried in the request body. It would be nice to have some more examples, especially from non-HTTP based protocols. Since we also want the maximum level of backward compatibility with existing applications, some of which may be buggy in this area, and we have limited information about what they actually do, there is significant controversy about what the draft should say. Since this issue impacts the library API and application logic, which are outside the scope of our draft, I think Marsh Ray has the best approach when he writes: >What I think would be far more useful is a practical treatment of the >best practices and possible pitfalls for implementing and using typical >library APIs. Some of this is in Appendix D. Implementation Notes, but >it could be given its own section with advice like: > >* Although most TLS libraries will properly validate a cert, the >application code is usually still responsible for checking that the cert >identifies the intended host. This is because the exact method to be >used depends upon the application protocol in use. This check MUST be >done at the earliest opportunity during the handshake process. This >usually necessitates an application-supplied callback function be >registered with the TLS implementation. Returning a failure code from >the callback MUST terminate the handshake. > >* The TLS protocol allows application data to be interleaved within >rengotiation handshake messages. Sometimes this is desired, but may >require extra care. The application-supplied callback and TLS library >normally SHOULD discard any buffered plaintext at the point of >renegotiation. It is recommended that TLS libraries default to neither >sending nor accepting of application data during a renegotiation >(between the Hello and the Finished handshake messages). Cheers - Bill [1] To use David-Sarah's definition of channel where he referenced the channel bindings draft and RFC 5056. I hope the TLS 1.3 effort results in good names for all of these states of TLS so we can communicate better. [2] ------------------------------------------------------------------------- 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 wtc@google.com Thu Dec 3 13:32: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 0580528C1E0 for ; Thu, 3 Dec 2009 13:32: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=[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 4BAfrnSH0uaN for ; Thu, 3 Dec 2009 13:32:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 800AA28C1CE for ; Thu, 3 Dec 2009 13:32:40 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id nB3LWUHe006755 for ; Thu, 3 Dec 2009 21:32:30 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259875950; bh=9U445NwozdZC4Rp2vhgrh6jfEWQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=D1CysaSHMn18q1eEDgLBlxvHhS7uoyrE4MGL3HnIKPQPtwr7S//tmMY1xpZm2AUB2 lpa/SyWX8c7+IzYEkRD2A== 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=jWPGp4nbbijatCJiK8RY4GXyWGt+4F4HuZBi89eCjCoWg1NiAIT1vyqILo+egKCYX +NhEdYXZnWDG6/L9tFj+w== Received: from pwi16 (pwi16.prod.google.com [10.241.219.16]) by wpaz29.hot.corp.google.com with ESMTP id nB3LWP4w029797 for ; Thu, 3 Dec 2009 13:32:26 -0800 Received: by pwi16 with SMTP id 16so1529834pwi.17 for ; Thu, 03 Dec 2009 13:32:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.9.18 with SMTP id 18mr273765wfi.131.1259875945624; Thu, 03 Dec 2009 13:32:25 -0800 (PST) In-Reply-To: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> Date: Thu, 3 Dec 2009 13:32:25 -0800 Message-ID: From: Wan-Teh Chang To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 21:32:44 -0000 On Thu, Dec 3, 2009 at 12:23 PM, Martin Rex wrote: > > If you don't require the MCSV on all ClientHellos, then all > extension-tolerant servers must implement TLS extensions in order > to wade through the extensions sent by clients in order to find > an empty TLS extension RI or one that contains verify_data > from a Client.Finished message. We can do what Chris Newman suggested -- require that the RI extension be listed first in ClientHellos -- so that servers don't need to wade through the extensions to find RI. Wan-Teh From mrex@sap.com Thu Dec 3 13:37: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 8931A3A6945 for ; Thu, 3 Dec 2009 13:37:43 -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 0XsjgYLP8mSt for ; Thu, 3 Dec 2009 13:37: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 5B0E73A6858 for ; Thu, 3 Dec 2009 13:37:42 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB3LbV6u019324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 22:37:31 +0100 (MET) From: Martin Rex Message-Id: <200912032137.nB3LbUVM013512@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 3 Dec 2009 22:37:30 +0100 (MET) In-Reply-To: <4B1824F7.709@extendedsubset.com> from "Marsh Ray" at Dec 3, 9 02:52: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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 21:37:43 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Marsh Ray wrote: > >> > >> I for one would like to see the day (say in TLS 1.7) when we no longer > >> need to send the MCSV on every Client Hello. It is, after all, a hack. > >> > >> In order for this to ever be possible, we need servers from the first > >> implementation of this patch to accept and work with either the > >> extension or the MCSV. > >> > >> The MCSV was a concession to those who needed, on occasion, to not send > >> any extensions. It sounds like the great majority of servers do not > >> break when sent extensions. > >> > >> Modern browsers are sending the SNI extension, no need for the hack > >> there. Let them use the MCSV only for the (sigh) fall-back logic. > > > > > > Do you really want to punish _ALL_ the extensions-tolerant Servers > > that do not implement TLS extensions so far for being > > extensions-tolerant? Sounds like a pretty bad idea to me. > > What are you talking about? > > > If you don't require the MCSV on all ClientHellos, then all > > extension-tolerant servers must implement TLS extensions in order > > to wade through the extensions sent by clients > > Yes, they would need to parse the extensions rather than ignore them. > It's a 4 line 'for' loop, big deal. They don't have to add full support > for generic extension handling to their API to do this. > > > in order to find > > an empty TLS extension RI or one that contains verify_data > > from a Client.Finished message. > > There's no other way to supply verify_data. > > > That applies to all implementations > > of SSLv3,TLSv1.0,TLSv1.1 servers which do _not_ need renegotiation. > > I am not aware of any TLS implementations that do not support > renegotiation (although I'm sure they exist). > > > Extensions-intolerant are going to benefit most when they remain > > extensions-intolerant, becaus then they will have to look only > > for MCSV, which is minimal code. > > > > > > I'm sorry, but I think such an approach would be sending > > an extremely wrong message! > > Sorry, I'm not seeing the big message here. *I* would really like to give a message to the maintainers of old, extensions-intolerant servers that do not need renegotiation that they should fix the extensions-intolerance. That would normally be an extremely easy and obvious one-line change to their code. Mandating MCSV and SHOULD NOTting the empty TLS extension RI would save *EVERYONE* 3 octets per ClientHello, btw. But if we *NOT* mandate TLS extension RI, then this maintainer of the old extensions-intolerant server can either leave his server extensions-intolerant, look for MCSV (~3 lines of code) and append a fixed 7 octet string to ServerHello (~4 lines of code) and be done with it. When this maintainer fixes the extensions-intolerance, then he must not only do all of the above, but additionally add a non-trivial >25 lines of code to wade through TLS extensions looking for TLS extension RI and come up with a non-trivial test scenario to test that stuff. _NOT_ making MCSV is a REALLLLLY bad idea, because those who maintain an old extensions-intolerant server that doesn't need renegotiation would be ill-advised to make it extensions-tolerant. Chastizing everyone just because it looks nicer on paper is a pretty bad idea. Look at the issue the other way: Q: Can anyone save a single line of code from _NOT_ mandating MCSV? A: No! it will require at least the same amount of code, and for some it will require more code in the TLS implementation, create two code-paths and duplicate the test-scenarios! Q: Do we at least save bandwidth by doing so? A No. everyone will pay 3 octets extra on every initial ClientHello! Can you demonstrate a substantial benefit? > > The fix we have with requires an extension. Implementations will have to > handle it, but it's pretty minimal. You are asking people to parse data from the network that comes in small chunks with variable length fields and embedded length fields. I would suggest that you go through the monthly security bulletins from Microsoft and count the hotfixes for bugs in similar parsers (various graphics formats, Word, Excel, PPT and media-files), to realize that "oh this is just a simple loop" might not be a very sensible approach to implement such a parser. -Martin From mike-list@pobox.com Thu Dec 3 13: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 3643D28C1C7 for ; Thu, 3 Dec 2009 13:43:20 -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 d8azFQlaBaWQ for ; Thu, 3 Dec 2009 13:43:19 -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 5A1F328C18F for ; Thu, 3 Dec 2009 13:43:19 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6942D85F4F for ; Thu, 3 Dec 2009 16:43: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=9bZaY7hUKSDn WOVhZ0tPojD56Gk=; b=OU+n4hpwfezvxxGgZwluAEO7VHjj+HJpVJ5H0jCAtX0E P29pGpgO+QRpwYNWdAYZsOYtaHiAxsIOlZhJkCz36k+H4KuGTNu8/BZvkUMIitNL o+C5AeHCPxU65nnyafEwRsLtLBSqY5kTFES0YUWbOqEcIDRSj3NwihNXsbwGLIA= 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=ahv3es Qz5Ne1lRsd38bf0JMe2xqqRrd+IXKaqYFlkKX45zMXArB/h5KPEctdwR9r4BPTZW XLDi3encUBNLaMCNQBTKNW68ohGjKRxn+mSae/CHpf/8XVgHU0QHSDETCPn5xUaC 5KjJEAqnH4FYqoeyrSXDUdPQQm2kmqVxFs9uE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6113F85F4E for ; Thu, 3 Dec 2009 16:43: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 EDA8985F4D for ; Thu, 3 Dec 2009 16:43:08 -0500 (EST) Message-ID: <4B18314E.3000002@pobox.com> Date: Thu, 03 Dec 2009 13:44:46 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@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: D9333BCA-E054-11DE-852A-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 21:43:20 -0000 Wan-Teh Chang wrote: > > We can do what Chris Newman suggested -- require that the > RI extension be listed first in ClientHellos -- so that servers > don't need to wade through the extensions to find RI. I think that the most we can/should do is RECOMMEND that the RI extension be first in the list. Extensions have always been an unordered set. Mike From marsh@extendedsubset.com Thu Dec 3 13:44: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 AFC6E3A69FD for ; Thu, 3 Dec 2009 13:44:11 -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 Bv9mC6o3IkD9 for ; Thu, 3 Dec 2009 13:44:09 -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 80DBB3A696C for ; Thu, 3 Dec 2009 13:44:09 -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 1NGJSy-0009gS-Q7; Thu, 03 Dec 2009 21:44:00 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7E9EB603C; Thu, 3 Dec 2009 21:43: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+r36ZZuCYPSlaNJ2fj8rcdCFIbjz+qUF4= Message-ID: <4B18311B.2090802@extendedsubset.com> Date: Thu, 03 Dec 2009 15:43:55 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Wan-Teh Chang References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@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 Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 21:44:11 -0000 Wan-Teh Chang wrote: > On Thu, Dec 3, 2009 at 12:23 PM, Martin Rex wrote: >> If you don't require the MCSV on all ClientHellos, then all >> extension-tolerant servers must implement TLS extensions in order >> to wade through the extensions sent by clients in order to find >> an empty TLS extension RI or one that contains verify_data >> from a Client.Finished message. > > We can do what Chris Newman suggested -- require that the > RI extension be listed first in ClientHellos -- so that servers > don't need to wade through the extensions to find RI. Not good I think. That amounts to just defining it as a new fixed field on the Hello structure. Now you're really forcing implementors who did it the right way to add special logic to ensure this special-case ordering. What happens the next time an extension wants to be first? In my experience, one will end up with the best compatibility by having the extension randomized well over the possible orderings. The specs could have been made to say "parties sending multiple extensions SHOULD randomize the order in which they are sent". But somehow I doubt this group, collectively, has the stomach for that sort of thing and I expect to be ridiculed for suggesting it. :-) - Marsh From mbadra@gmail.com Thu Dec 3 13: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 A833C3A6989 for ; Thu, 3 Dec 2009 13:47:52 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4N5tsPK8G0EF for ; Thu, 3 Dec 2009 13:47:51 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 9FEC43A68D0 for ; Thu, 3 Dec 2009 13:47:51 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e21so870610fga.13 for ; Thu, 03 Dec 2009 13:47:39 -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=GzM2B/17VQNZeaAmJeDcfoYaLtvVDsMBmFM2CnRohZE=; b=FqIoMKZijUvetr5qmBz+R5tjR9eY7HR72JyoHgIii1gDznNFNm4DNYf8O3zpQehbV7 nQtbzB9GjK9sPhaWaZ1Td7/LwwJQZIBwk6nDxUJnBrx7LRWolLmmBkKpe6P/oTQqfx5R bD/461rbZwoaWlOH3Js8LvNOwrItdU/PTaanI= 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=wVDHQtk+CP5TpQzsYLH3JC3llPdLglsGvDF8Ld7NP85nT0XF6h9PcWeGA9wHZ6TeLW YBGwkk4gDh4+4NGWnqFTMMV4L8IiX6ql4KY4C7BW4BHxgYRYzoWCXlQFZq8ijDuaniyQ JrSE2YhcJ+5hkH98ohRxeqkmoNIAtCSeiOPE8= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.239.138.12 with SMTP id n12mr218243hbn.69.1259876858898; Thu, 03 Dec 2009 13:47:38 -0800 (PST) In-Reply-To: References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> Date: Thu, 3 Dec 2009 22:47:38 +0100 X-Google-Sender-Auth: 8494eee1479a53cd Message-ID: From: Badra To: Wan-Teh Chang Content-Type: multipart/alternative; boundary=001485f778daa2ac210479d9f0de Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 21:47:52 -0000 --001485f778daa2ac210479d9f0de Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 3, 2009 at 10:32 PM, Wan-Teh Chang wrote: > On Thu, Dec 3, 2009 at 12:23 PM, Martin Rex wrote: > > > > If you don't require the MCSV on all ClientHellos, then all > > extension-tolerant servers must implement TLS extensions in order > > to wade through the extensions sent by clients in order to find > > an empty TLS extension RI or one that contains verify_data > > from a Client.Finished message. > > We can do what Chris Newman suggested -- require that the > RI extension be listed first in ClientHellos -- so that servers > don't need to wade through the extensions to find RI. > RFC5246: When multiple extensions of different types are present in the ClientHello or ServerHello messages, the extensions MAY appear in any order. Badra --001485f778daa2ac210479d9f0de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 3, 2009 at 10:32 PM, Wan-Teh= Chang <wtc@google.c= om> wrote:
On Thu, Dec 3, 2009 at 12:23 PM, Martin Rex <mrex@sap.com> wrote:
>
> If you don't require the MCSV on all ClientHellos, then all
> extension-tolerant servers must implement TLS extensions in order
> to wade through the extensions sent by clients in order to find
> an empty TLS extension RI or one that contains verify_data
> from a Client.Finished message.

We can do what Chris Newman suggested -- require that the
RI extension be listed first in ClientHellos -- so that servers
don't need to wade through the extensions to find RI.
<= div>=A0

RFC5246:

=A0=A0=A0 When multiple extens= ions of different types are present in the
=A0=A0=A0 ClientHello or Se= rverHello messages, the extensions MAY appear in any
=A0=A0=A0 order.

Badra
=A0

--001485f778daa2ac210479d9f0de-- From mrex@sap.com Thu Dec 3 13:49: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 6C8F33A657C for ; Thu, 3 Dec 2009 13:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 XXdDDtM94ayS for ; Thu, 3 Dec 2009 13:49: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 537863A6849 for ; Thu, 3 Dec 2009 13:49:40 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB3LnPv0003325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 22:49:25 +0100 (MET) From: Martin Rex Message-Id: <200912032149.nB3LnOwB014298@fs4113.wdf.sap.corp> To: wtc@google.com (Wan-Teh Chang) Date: Thu, 3 Dec 2009 22:49:24 +0100 (MET) In-Reply-To: from "Wan-Teh Chang" at Dec 3, 9 01:32: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: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 21:49:41 -0000 Wan-Teh Chang wrote: > > On Thu, Dec 3, 2009 at 12:23 PM, Martin Rex wrote: > > > > If you don't require the MCSV on all ClientHellos, then all > > extension-tolerant servers must implement TLS extensions in order > > to wade through the extensions sent by clients in order to find > > an empty TLS extension RI or one that contains verify_data > > from a Client.Finished message. > > We can do what Chris Newman suggested -- require that the > RI extension be listed first in ClientHellos -- so that servers > don't need to wade through the extensions to find RI. I would strongly recommend AGAINST this! TLS extensions are defined to NOT have an ordering, so such a constraint is going to cause headaches and interop problems. Any such requirements will result in more code and more interop problems for everyone! PLEASE DON'T! Here is another example for a vaguely related interop problem: The Certificate message is defined to contain an ordered list of certificates. All implementation put the EndEntity cert in the correct posistion (first), but there are some that make an extremely poor job about the rest (OpenSSL), because they append whatever they receive from the "application" and neither care about ordering, nor whether the given certs form a chain. No Microsoft is using CPU-intensive generic functions to sort all certificates following the EndEntity cert so that they build a chain with the EndEntity cert. You will find Apache Servers out there which are using Server-Certs from multilevel CA-hierarchies and these servers will send the chain certificates in obvious violation of the SSL&TLS protocol unordered. When accessing that server with MSIE, you will likely not notice that. Compliant TLS clients should complain about the defective certificate chain sent by the server. -Martin From stefan@aaa-sec.com Thu Dec 3 13:54: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 ABBF73A689E for ; Thu, 3 Dec 2009 13:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 tZIalqKBvPx2 for ; Thu, 3 Dec 2009 13:54:58 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id D7F033A657C for ; Thu, 3 Dec 2009 13:54:56 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id CAC512B4261 for ; Thu, 3 Dec 2009 22:54:06 +0100 (CET) Received: (qmail 29149 invoked from network); 3 Dec 2009 21:53: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 ; 3 Dec 2009 21:53:57 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 03 Dec 2009 22:53:56 +0100 From: Stefan Santesson To: Wan-Teh Chang , Message-ID: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Thread-Index: Acp0YxxeAd5rOL65/EOplDflwndshA== 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 21:54:58 -0000 Such requirements scares me. What if another unrelated future document decides to put in a similar requirement, then what should implementers do? Recommending would be fine though. /Stefan On 09-12-03 10:32 PM, "Wan-Teh Chang" wrote: > On Thu, Dec 3, 2009 at 12:23 PM, Martin Rex wrote: >> >> If you don't require the MCSV on all ClientHellos, then all >> extension-tolerant servers must implement TLS extensions in order >> to wade through the extensions sent by clients in order to find >> an empty TLS extension RI or one that contains verify_data >> from a Client.Finished message. > > We can do what Chris Newman suggested -- require that the > RI extension be listed first in ClientHellos -- so that servers > don't need to wade through the extensions to find RI. > > Wan-Teh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Thu Dec 3 14:12: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 1884828C1B8 for ; Thu, 3 Dec 2009 14:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyjVm9R5YwRe for ; Thu, 3 Dec 2009 14:12:19 -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 2C2A43A682E for ; Thu, 3 Dec 2009 14:12:19 -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 1NGJuE-000GQ5-AR; Thu, 03 Dec 2009 22:12:10 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 26430603C; Thu, 3 Dec 2009 22:12: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: U2FsdGVkX18u5jPBNb1LjPUT9n8vELXjsB9pxbOh+sM= Message-ID: <4B1837B5.6040903@extendedsubset.com> Date: Thu, 03 Dec 2009 16:12:05 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912032137.nB3LbUVM013512@fs4113.wdf.sap.corp> In-Reply-To: <200912032137.nB3LbUVM013512@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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 22:12:27 -0000 Martin Rex wrote: > > *I* would really like to give a message to the maintainers of old, > extensions-intolerant servers that do not need renegotiation that > they should fix the extensions-intolerance. Oh some of those jokers I would really love to give a stern talking-to. But, please, this bug fix is challenging enough, let us not complicate it further by bundling additional motivations? > That would normally > be an extremely easy and obvious one-line change to their code. > > Mandating MCSV and SHOULD NOTting the empty TLS extension RI > would save *EVERYONE* 3 octets per ClientHello, btw. > > But if we *NOT* mandate TLS extension RI, > then this maintainer of the old extensions-intolerant server > can either leave his server extensions-intolerant, look for > MCSV (~3 lines of code) and append a fixed 7 octet string > to ServerHello (~4 lines of code) and be done with it. So freaking what? If he's doesn't renegotiate, he's secure. If he does renegotiate, he's still insecure and is going to get publicly pwned and consumers will know this vendor is incompetent and market forces will take it from there. In either case, he's no more broken than he was before, and the net as a whole is no worse off. > When this maintainer fixes the extensions-intolerance, > then he must not only do all of the above, but additionally > add a non-trivial >25 lines of code to wade through I'd say it's pretty trivial, but maybe that's because I've written a quarter-million lines or so of that kind of code. > TLS extensions looking for TLS extension RI and come up with > a non-trivial test scenario to test that stuff. I'll wager some combination of openssl s_cilent and/or Firefox will soon do the trick. Nothing that esoteric. > _NOT_ making MCSV is a REALLLLLY bad idea, because those who > maintain an old extensions-intolerant server that doesn't need > renegotiation would be ill-advised to make it extensions-tolerant. You're saying not only will it not encourage them to fix it, but it will actively discourage them from fixing it? > Chastizing everyone just because it looks nicer on paper > is a pretty bad idea. I don't get this part. > Look at the issue the other way: > > Q: Can anyone save a single line of code from _NOT_ mandating MCSV? > > A: No! it will require at least the same amount of code, > and for some it will require more code in the TLS implementation, > create two code-paths and duplicate the test-scenarios! A2: Yes, someday in the future the lines of code which send and receive the MCSV can be joyfully deleted. > Q: Do we at least save bandwidth by doing so? > > A No. everyone will pay 3 octets extra on every initial ClientHello! > > Can you demonstrate a substantial benefit? Yes. A consistent Hello Extension mechanism is worth it's weight in gold. This whole discussion is solely because it was inconsistently implemented in the first place. >> The fix we have with requires an extension. Implementations will have to >> handle it, but it's pretty minimal. > > You are asking people to parse data from the network that comes in > small chunks with variable length fields and embedded length fields. Yes. You really should meet some of these network protocol implementors some time, they really are pretty good with the small chunks. > I would suggest that you go through the monthly security bulletins > from Microsoft and count the hotfixes for bugs in similar parsers > (various graphics formats, Word, Excel, PPT and media-files), > to realize that "oh this is just a simple loop" might not be > a very sensible approach to implement such a parser. I'm not saying it's fool-proof or that no one can screw it up, but if, as part of this patch, Microsoft ships a length overrun bug in parsing TLS hello extensions I will concede your point and buy you beer and pizza. - Marsh From Nicolas.Williams@sun.com Thu Dec 3 14:26: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 450EF28C1BD for ; Thu, 3 Dec 2009 14:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.828 X-Spam-Level: X-Spam-Status: No, score=-5.828 tagged_above=-999 required=5 tests=[AWL=0.218, 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 S2UTpw+QIlLT for ; Thu, 3 Dec 2009 14:26: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 3126328C1B8 for ; Thu, 3 Dec 2009 14:26:15 -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 nB3MQ6Ij003638 for ; Thu, 3 Dec 2009 22:26:06 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 nB3MQ6lX010811 for ; Thu, 3 Dec 2009 15:26: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 nB3MEL7c009273; Thu, 3 Dec 2009 16:14:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB3MEK00009272; Thu, 3 Dec 2009 16:14:20 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Dec 2009 16:14:20 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091203221420.GZ773@Sun.COM> References: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B171AC0.6090403@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: william.polk@nist.gov, tls@ietf.org Subject: [TLS] Defining "TLS channel" (Re: Last Call: draft-ietf-tls-renegotiation (Transport Layer) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 22:26:16 -0000 On Thu, Dec 03, 2009 at 01:56:16AM +0000, David-Sarah Hopwood wrote: [Discussion of the meaning of "session" and "connection" elided.] > >> To be more precise, sessions are delimited by *full* handshakes. > >> > >>> "between sessions" is correct; "between connections" or > >>> "between transport layer connections" is wrong. > >> This is accurate. > > > > I would not call that accurate. The lack of clear terminology in > > the TLS protocol specs precludes a determination of accuracy. > > On reflection you're right. TLS 1.2 defines what a "session" is in > section 7, and it is not consistent with what I said above (because > there may be multiple instances of the same session). > > The concept we want is precisely a "channel", as defined in the > channel bindings draft and in RFC 5056. Fortunately the TLS RFC > does not already use this term in a way that would be inconsistent > with this meaning. > > The channels we want to use here are identified by the contents > of a pair of Finished messages, i.e. each Finished message pair > starts a new channel. As the author of RFC5056, and co-author of draft-altman-tls-channel- bindings[*]: +1e6 I hesitate to request any additional changes to draft-ietf-tls- renegotiation given that the surrounding threads have been a horrible DDoS on us all. But if there's any way to get into it a definition of "TLS channel" in the RFC5056 sense, it'd be great if we could. Alternatively, perhaps draft-altman-tls-channel-bindings, which defines (or soon will) the term ought to update RFC5246. I'm particularly interested in hearing from the Security ADs (cc'ed) how important they think it is that we properly define the term "TLS channel", and what vehicle is best for that purpose. [*] Where we've had to grapple with how best to word a definition of "TLS channel" -- a very painful excercise that led to Martin's independent re-discovery of the re-negotiation vulnerability. Nico -- From peter.robinson@rsa.com Thu Dec 3 14:30: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 E2DAE3A6A86 for ; Thu, 3 Dec 2009 14:30:45 -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 lroh0+i+vyud for ; Thu, 3 Dec 2009 14:30:44 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 96C4E3A6809 for ; Thu, 3 Dec 2009 14:30:44 -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 nB3MUZvm008589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Dec 2009 17:30:35 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 3 Dec 2009 17:30:29 -0500 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2mp) with ESMTP id nB3MUSJJ001545 for ; Thu, 3 Dec 2009 17:30:29 -0500 Received: from CORPUSMX100B.corp.emc.com ([128.222.76.51]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 17:30:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Dec 2009 17:30:27 -0500 Content-Type: multipart/signed; boundary="----=_NextPart_000_0050_01CA74BC.08129670"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: TLS Renegotiate: empty extension and TLS_RENEGO_PROTECTION_REQUEST cipher suite thread-index: Acpx0138KCsc0GUGQXikdtGWh19/SgBTPLQgAFGsgrA= References: <20091130153734.D44C63A6AA9@core3.amsl.com> From: To: X-OriginalArrivalTime: 03 Dec 2009 22:30:28.0969 (UTC) FILETIME=[377AB590:01CA7468] X-EMM-EM: Active Subject: [TLS] TLS Renegotiate: empty extension and TLS_RENEGO_PROTECTION_REQUEST cipher suite X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 22:30:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0050_01CA74BC.08129670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In draft-ietf-tls-renegotiation-01.txt, in section 4 last paragraph the draft discusses a minimal client. It says: >Any compliant server will reject any (apparent) attempt >at renegotiation by such a client. And in section 3 it says: >If the contents >are incorrect, then it MUST generate a fatal "handshake_failure" >alert and terminate the connection. This implies that the cipher suite TLS_RENEGO_PROTECTION_REQUEST is not entirely equivalent to an empty renegotiation_info extension. If a server receives an empty renegotiation_info extension on a rehandshake then it must generate a fatal "handshake_failure" alert and terminate the connection. If a server receives a TLS_RENEGO_PROTECTION_REQUEST cipher suite on a rehandshake then it merely rejects the renegotiation (by generating a "no_renegotiation" alert at warning level). I think that the paragraph in section 4 should be altered to say: >Any compliant server MUST generate a fatal "handshake_failure" >alert and terminate the connection when it sees any (apparent) attempt >at renegotiation by such a client. ------------------------------------------------ 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_0050_01CA74BC.08129670 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 AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTIwMzIyMzAyN1owIwYJKoZIhvcNAQkE MRYEFD7BZOeh9X+Woh1RQwsAI42qLySLMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGzBgkrBgEEAYI3EAQxgaUwgaIwgYwxGjAYBgNVBAoTEVJTQSBTZWN1 cml0eSBJbmMuMRUwEwYDVQQLEwxLQ0EgU2VydmljZXMxIDAeBgNVBAMTF1JTQSBDbGFzcyAyIFBl cnNvbmFsIENBMRAwDgYDVQQHEwdCZWRmb3JkMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMQswCQYD VQQGEwJVUwIRAKofbFRtKhp4TVAszoeZalYwgbUGCyqGSIb3DQEJEAILMYGloIGiMIGMMRowGAYD VQQKExFSU0EgU2VjdXJpdHkgSW5jLjEVMBMGA1UECxMMS0NBIFNlcnZpY2VzMSAwHgYDVQQDExdS U0EgQ2xhc3MgMiBQZXJzb25hbCBDQTEQMA4GA1UEBxMHQmVkZm9yZDEWMBQGA1UECBMNTWFzc2Fj aHVzZXR0czELMAkGA1UEBhMCVVMCEQCqH2xUbSoaeE1QLM6HmWpWMA0GCSqGSIb3DQEBAQUABIGA JHEcRKQ8g84ry8Z4ffM3Vx5+bVwk1Far++BO6g4EJr75hrAkDT9b5w1OJIkW7Jdt+qqr+Br82d7g e0LusfAMR+zQspGJdAw56Nm347WylwIdCk4F1iA26cs9JjtRqNVm9tIVy6xuzmKLlqEzrTwnRXbR ckhX9itrkmLtXU3l/hYAAAAAAAA= ------=_NextPart_000_0050_01CA74BC.08129670-- From ekr@networkresonance.com Thu Dec 3 14:58: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 83A263A68F7 for ; Thu, 3 Dec 2009 14:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.97 X-Spam-Level: X-Spam-Status: No, score=0.97 tagged_above=-999 required=5 tests=[AWL=0.075, 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, 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 kDJdPXRf9AhO for ; Thu, 3 Dec 2009 14:58:53 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id D3A303A6809 for ; Thu, 3 Dec 2009 14:58:53 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 09B666C4B14; Thu, 3 Dec 2009 15:00:07 -0800 (PST) Date: Thu, 03 Dec 2009 15:00:07 -0800 From: Eric Rescorla To: In-Reply-To: References: <20091130153734.D44C63A6AA9@core3.amsl.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: <20091203230008.09B666C4B14@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] TLS Renegotiate: empty extension and TLS_RENEGO_PROTECTION_REQUEST cipher suite X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 22:58:54 -0000 At Thu, 3 Dec 2009 17:30:27 -0500, wrote: > > [1 ] > [1.1 ] > > In draft-ietf-tls-renegotiation-01.txt, in section 4 last paragraph the draft > discusses a minimal client. It says: > > >Any compliant server will reject any (apparent) attempt > >at renegotiation by such a client. > > And in section 3 it says: > > >If the contents > >are incorrect, then it MUST generate a fatal "handshake_failure" > >alert and terminate the connection. > > This implies that the cipher suite TLS_RENEGO_PROTECTION_REQUEST is not > entirely equivalent to an empty renegotiation_info extension. If a server > receives an empty renegotiation_info extension on a rehandshake then it must > generate a fatal "handshake_failure" alert and terminate the connection. If a > server receives a TLS_RENEGO_PROTECTION_REQUEST cipher suite on a rehandshake > then it merely rejects the renegotiation (by generating a "no_renegotiation" > alert at warning level). > I think that the paragraph in section 4 should be altered to say: > > >Any compliant server MUST generate a fatal "handshake_failure" > >alert and terminate the connection when it sees any (apparent) attempt > >at renegotiation by such a client. That sounds right. I'll add this to my TODO list unless someone objects. -Ekr From peter.sylvester@edelweb.fr Thu Dec 3 15:00: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 9B9E53A691E for ; Thu, 3 Dec 2009 15:00: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 ESekF2pRZs8a for ; Thu, 3 Dec 2009 15:00:42 -0800 (PST) Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by core3.amsl.com (Postfix) with ESMTP id 796253A6809 for ; Thu, 3 Dec 2009 15:00:42 -0800 (PST) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 327E5164 for ; Fri, 4 Dec 2009 00:00:11 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 2CC31170AC for ; Fri, 4 Dec 2009 00:00:11 +0100 (CET) Received: from [192.168.0.26] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 67FF27877 for ; Thu, 3 Dec 2009 23:59:48 +0100 (CET) Message-ID: <4B1842F3.9050206@edelweb.fr> Date: Fri, 04 Dec 2009 00:00:03 +0100 From: Peter Sylvester User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: tls@ietf.org References: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> In-Reply-To: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 23:00:43 -0000 Hi, What would have been a fix to SSL when no extensions would be available (and if one wouldn't care about the signaling); On a renegotiation wouldn't taking the two previous finished messages and insert them between the client and server hello for hash calculation have solved the problem? /PS From marsh@extendedsubset.com Thu Dec 3 15:05: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 24FE43A68DD for ; Thu, 3 Dec 2009 15:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt8oDURuswlT for ; Thu, 3 Dec 2009 15:05: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 5A75F3A62C1 for ; Thu, 3 Dec 2009 15:05: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 1NGKjV-000EPg-KV; Thu, 03 Dec 2009 23:05:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DFEDC603C; Thu, 3 Dec 2009 23:05: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: U2FsdGVkX1/bRWzbrDGjD2XVjo2lWyzwPY7c1J1ZTOs= Message-ID: <4B184420.9090509@extendedsubset.com> Date: Thu, 03 Dec 2009 17:05:04 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Sylvester References: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B1842F3.9050206@edelweb.fr> In-Reply-To: <4B1842F3.9050206@edelweb.fr> 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 23:05:19 -0000 Peter Sylvester wrote: > Hi, > > What would have been a fix to SSL when no > extensions would be available > (and if one wouldn't care about the signaling); > > On a renegotiation wouldn't taking the two > previous finished messages and insert them > between the client and server hello > for hash calculation have solved the problem? yes - Marsh From nelson@bolyard.me Thu Dec 3 15:05: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 A461D3A68D1 for ; Thu, 3 Dec 2009 15:05:25 -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 hCammqFqpcwX for ; Thu, 3 Dec 2009 15:05:24 -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 123C63A62C1 for ; Thu, 3 Dec 2009 15:05:24 -0800 (PST) Received: (qmail 29486 invoked from network); 3 Dec 2009 23:05:15 -0000 Received: from unknown (24.5.142.42) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 03 Dec 2009 23:05:15 -0000 Message-ID: <4B1843B8.3020806@bolyard.me> Date: Thu, 03 Dec 2009 15:03:20 -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: <4B17C2F9.9010802@extendedsubset.com> <4B18096E.20805@extendedsubset.com> In-Reply-To: <4B18096E.20805@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 23:05:25 -0000 On 2009-12-03 10:54 PST, Marsh Ray wrote: > Bodo Moeller wrote: >>> These may be communicated over the same pool of active socket >>> connections, as Nelson Bolyard of NSS (heir of the Netscape legacy >>> implementation, twice removed) has described. NSS _is_ the Netscape legacy implementation, much evolved. >> Where has he described this? (Sorry -- I've tried to find something >> using various keywords, but to no avail.) > > Sorry, I think it may have been a private mail. Nelson, would you mind > posting that? I refer to it often. I have it in my box dated 10/16/2009 > 6:27 PM Message-ID: <4AD90164.6080304@bolyard.me>. > > I'm sure he wouldn't mind me sharing this tidbit: I don't mind a bit. > "It is also possible that, in response to a client hello request, the > client will send a client hello bearing a session ID that is not empty > and is NOT the session ID of the session presently in use on that > connection. This can happen when the client has multiple connections > going in parallel between the same client identity session cache and the > same remote server." To explain that slightly, NSS explicitly allows a process to act as multiple independent client entities, e.g. multiple virtual http clients, each with its own separate TLS session cache, so that each entity can restart its own TLS sessions, and not accidentally restart sessions of another entity. This greatly facilitates writing test clients that simulate large numbers of independent clients all pounding on a test server for (e.g.) benchmark purposes. Most client apps only operate as a single entity and only use one client identity cache, so it was a detail that's not necessarily important to this discussion. But if an app wants to have multiple connections to the same server, with some of them client authenticated with some identity, and others not authenticated, or authenticated with a different identity, then it should use a separate cache for each of those identities, including one for the anonymous (non-authenticated) identity. A single client entity may have multiple sockets open, with multiple TLS connections to the same server, and multiple of those connections may be using the same TLS session (the same session ID). Generally, whenever any handshake (initial or renegotiation) occurs with a server, the code finds the TLS session most recently established with that server in that client entity's session cache, and offers that session's ID in the client hello. So, if a client has multiple connections going to a server, all sharing the same client entity's session cache, and it renegotiates on one connection with a full handshake, establishing a new TLS session (with or without client authentication), then the next time it renegotiates on any connection to that same server, it will offer in the client hello the most recently initiated session ID, even if that is not the session ID that was already in use on that connection. > Now I don't perfectly understand how Mozilla handles its "client > identity session cache" (I suspect no one does), > but it sounds plausible to me that renegotiation with resumption could, > in theory, switch between differing client certs over the same > connection. Switch between different TLS sessions that had bee previously authenticated with different certs. Yes, I agree completely. I see TLS as being capable of multiplexing multiple independent sessions over a single connection. Perhaps it's not terribly efficient at that -- the round trip time cost of switching sessions (doing session-restart handshakes) is at least as great as the cost of a 3-phase connection -- but I read nothing in the SSL/TLS specs that disallow it, and I have seen it used, at least experimentally in development. > This might be fun to test, actually. > >>> If someone wants to write a TLS application layer protocol that way, >>> there's no good reason for the spec to prohibit it at this stage in >>> the game. I agree that we should not absolutely prohibit it. But clearly most of the people who have ever coded apps to use SSL/TLS have never contemplated this session multiplexing capability, and have imagined that TLS was always about a secure connection between a single pair of these (loosely defined) entities. So, it might be good to suggest that TLS implementations operate BY DEFAULT in a mode that supports that all-too-common assumption, and if desired, offer a session multiplexing mode as a selectable alternative that is not the default. But this is API advice. I see no reason for the over-the-wire protocol specification to prohibit it. > What I think would be far more useful is a practical treatment of the > best practices and possible pitfalls for implementing and using typical > library APIs. Some of this is in Appendix D. Implementation Notes, but > it could be given its own section with advice like: > > * Although most TLS libraries will properly validate a cert, the > application code is usually still responsible for checking that the cert > identifies the intended host. This is because the exact method to be > used depends upon the application protocol in use. This check MUST be > done at the earliest opportunity during the handshake process. This > usually necessitates an application-supplied callback function be > registered with the TLS implementation. Returning a failure code from > the callback MUST terminate the handshake. > > * The TLS protocol allows application data to be interleaved within > rengotiation handshake messages. Sometimes this is desired, but may > require extra care. The application-supplied callback and TLS library > normally SHOULD discard any buffered plaintext at the point of > renegotiation. It is recommended that TLS libraries default to neither > sending nor accepting of application data during a renegotiation > (between the Hello and the Finished handshake messages). > > and so on... I agree that implementation guidance is a good thing. For a long time, there has been a certain tension between those who think that IETF RFCs should be only concise and precise specifications, with a minimum of extra verbiage, and those who think that implementation guidance is important, especially in security protocols. Count me in the latter group. In the history of SSL/TLS we have seen numerous instances where a little more explicit implementation guidance would have gone a long way to avoiding certain divisive implementation problems. One example is the stripping of leading zero bits from derived DH/DHE pre-master secrets, which seemed obviously wrong to mathematicians and obviously right to most of the early implementers (but I digress). One of the later versions of TLS addressed this explicitly. It could have been avoided with a little more guidance from the beginning. From nelson@bolyard.me Thu Dec 3 15: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 116DC28C0EE for ; Thu, 3 Dec 2009 15:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-hJYwSvXqjN for ; Thu, 3 Dec 2009 15:07:37 -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 321323A62C1 for ; Thu, 3 Dec 2009 15:07:37 -0800 (PST) Received: (qmail 19469 invoked from network); 3 Dec 2009 23:07:23 -0000 Received: from unknown (24.5.142.42) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 03 Dec 2009 23:07:23 -0000 Message-ID: <4B184438.9040308@bolyard.me> Date: Thu, 03 Dec 2009 15:05:28 -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: <200912030225.nB32PHkW003916@fs4113.wdf.sap.corp> <4B181209.5090507@extendedsubset.com> In-Reply-To: <4B181209.5090507@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 23:07:38 -0000 On 2009-12-03 11:31 PST, Marsh Ray wrote: > > I'm thinking this is the only big sticking point left for > draft-ietf-tls-renegotiation? > > > Martin Rex wrote: >> We do *NOT* need more than one signaling mechanism, so the use of >> MCSV needs to be a MUST and the use of an empty TLS extension RI >> on the initial ClientHello needs to be a SHOULD NOT. > > I for one would like to see the day (say in TLS 1.7) when we no longer > need to send the MCSV on every Client Hello. It is, after all, a hack. > > In order for this to ever be possible, we need servers from the first > implementation of this patch to accept and work with either the > extension or the MCSV. > > The MCSV was a concession to those who needed, on occasion, to not send > any extensions. It sounds like the great majority of servers do not > break when sent extensions. > > Modern browsers are sending the SNI extension, no need for the hack > there. Let them use the MCSV only for the (sigh) fall-back logic. > > - Marsh Hear! Hear! From mrex@sap.com Thu Dec 3 15:19: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 8E2BB3A635F for ; Thu, 3 Dec 2009 15:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Hz2gbl5oL56u for ; Thu, 3 Dec 2009 15:19: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 7C3C73A62C1 for ; Thu, 3 Dec 2009 15:19:20 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB3NInVC017514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 00:18:49 +0100 (MET) From: Martin Rex Message-Id: <200912032318.nB3NIn6q019735@fs4113.wdf.sap.corp> To: peter.sylvester@edelweb.fr (Peter Sylvester) Date: Fri, 4 Dec 2009 00:18:49 +0100 (MET) In-Reply-To: <4B1842F3.9050206@edelweb.fr> from "Peter Sylvester" at Dec 4, 9 00:00:03 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 03 Dec 2009 23:19:22 -0000 Peter Sylvester wrote: > > Hi, > > What would have been a fix to SSL when no > extensions would be available > (and if one wouldn't care about the signaling); > > On a renegotiation wouldn't taking the two > previous finished messages and insert them > between the client and server hello > for hash calculation have solved the problem? If it has been part of the original design of renegotiation, that would have completely solved the problem. But as soon as you have an installed base with this vulnerability, you need to distinguish vulnerable from patched, and have a need for signaling. -Martin And nobody would be lamenting that there could be buggy implementations out there that would add a finished message inserted by an attacker to the handshake message hash and otherwise completely ignore it. From mbadra@gmail.com Thu Dec 3 15:35: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 7A24A3A6816 for ; Thu, 3 Dec 2009 15:35:19 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ODImyRFEZU68 for ; Thu, 3 Dec 2009 15:35:18 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 454AF3A6840 for ; Thu, 3 Dec 2009 15:35:18 -0800 (PST) Received: by fxm10 with SMTP id 10so2189921fxm.14 for ; Thu, 03 Dec 2009 15:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5Aj7ZqBmcGqTrln2hrn2eW8UDwDO25GuVApSY56vnQ4=; b=vQtPb2aTBOsBTPXMamY1HJmdOgsbDSqYuhRYRdi5G6qiV1OXAiJW87f7wSlh6y5s9K awmA/F46lp+aFKhiAKo4iOT6u7dQCNGrvCRX2/GOSbOI1DcCBevz2h/n74525tcita80 93dMLxpVIKIF5p+aM3iw82EsayiahiLIr5o/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=iP7tsaLDEJIqATgnM7K05+Wq5UIyEZDaHBoPvuKZ617lhaxyhrjVbzfNiEdLluRzij DDiD6DIdm7PXirJJIE+DDbwIP8Tu0GY9st31hZNgWT0IdXkqyXNNfVJ11xPn/+/UsbNX jH7Wsv/FiCRMg/0oOnWfoUzTL5Bgd0dN65SHA= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.239.139.165 with SMTP id t37mr253340hbt.75.1259883305583; Thu, 03 Dec 2009 15:35:05 -0800 (PST) Date: Fri, 4 Dec 2009 00:35:05 +0100 X-Google-Sender-Auth: a41368db7c219579 Message-ID: From: Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=001485f5b090e3462b0479db704d Subject: [TLS] TLS Renegotiation Indication by adding some meaning to radom values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 23:35:19 -0000 --001485f5b090e3462b0479db704d Content-Type: text/plain; charset=ISO-8859-1 Hi, Some of TLS parameters are opaque values, but if we provide them some meaning or structuration, they may help processing the Server <--> Client signaling in ServerHello and ClientHello. I think the random values (or the session identifier) may help to cryptographically bind renegotiation handshakes to the enclosing TLS channel. IMO, there is no security concerns if, during the initial handshake, a client generates a random value - using RFC 4086 (recommanded by RFC5246) - removes the higher 2 bytes from the value and then delimits the result (26-byte_random_value) with a special character SP (1 octet), so the client replaces the generated 28-byte_random_value with SP|26-byte_random_value|SP (| denotes concatenation). A patched server must parse the client random value to check if it is delimited and if then it must repeat the same way as the patched client to generate its random value. Therefore, the patched client is able to parse the random value and to detect whatever the server in face is patched or not. if then both the client ad the server will use, during the renegotiation handshake, the verify_data from Finished messages as random values. But random values are 28 octes (ignoring the GMT time for now). Three cases are possible: - the length of the verify-data is less 28 bytes: some computation is needed to extend it to become 28 (using PRF for example) - the length is more than 28: truncated value of 28-byte length should be used - the length is 28, do no computation. Best regards, Badra --001485f5b090e3462b0479db704d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Some of TLS parameters are opaque values, but if we provide them= some meaning or structuration, they may help processing the Server <--&= gt; Client signaling in ServerHello and ClientHello.

I think the ran= dom values (or the session identifier) may help to cryptographically bind r= enegotiation handshakes to the enclosing TLS channel. IMO, there is no secu= rity concerns if, during the initial handshake, a client generates a random= value - using RFC 4086 (recommanded by RFC5246) - removes the higher 2 byt= es from the value and then delimits the result (26-byte_random_value) with = a special character SP (1 octet), so the client replaces the generated 28-b= yte_random_value with SP|26-byte_random_value|SP (| denotes concatenation).=

A patched server must parse the client random value to check if it is d= elimited and if then it must repeat the same way as the patched client to g= enerate its random value. Therefore, the patched client is able to parse th= e random value and to detect whatever the server in face is patched or not.= if then both the client ad the server will use, during the renegotiation h= andshake, the verify_data from Finished messages as random values.

But random values are 28 octes (ignoring the GMT time for now). Three c= ases are possible:

- the length of the verify-data is less 28 bytes:= some computation is needed to extend it to become 28 (using PRF for exampl= e)
- the length is more than 28: truncated value of 28-byte length should be u= sed
- the length is 28, do no computation.

Best regards,
Badra

--001485f5b090e3462b0479db704d-- From djhopwood@googlemail.com Thu Dec 3 15: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 B2FAE3A6840 for ; Thu, 3 Dec 2009 15:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_46=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 EA8QntE4i6xW for ; Thu, 3 Dec 2009 15:41:50 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id AD76C3A6816 for ; Thu, 3 Dec 2009 15:41:49 -0800 (PST) Received: by ewy8 with SMTP id 8so2219997ewy.15 for ; Thu, 03 Dec 2009 15:41: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=F3No5+wpa2Nr6z5W5/ICkB5dYfl8kVWctQRffYQ6pDI=; b=BODdRtzs5hWlPjRngHRYqgxXOksJm1PH9f8iQtehQjRgQW9a832ITXUWoiPh+QQ7E9 yroCx2sKRV37wbLSCckuW71zbdBzc798NZis1mZ21B09N9jAq8jzEWAz++k/8etEL/uG 8xt9+r9l/60lNrgBr9Kqx92tMwMNS6Fkif76Q= 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=MIOgxRi6Tnz+vICX6g42AUl44zS/Mbe1QGWoTdIlB9X+t7I0yEdMc+p+kGemYmKVcC BoFVUhwLyYMOcyAXDbMWYTzFfrisWLLcjYA/ss3+hkvaKX2cnc442A2RxHCU/9uXm8RW scV005VYTuH6r6nIzMW9erlRYFutzIllafCaI= Received: by 10.213.100.13 with SMTP id w13mr2442402ebn.15.1259883698254; Thu, 03 Dec 2009 15:41:38 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm1601774ewy.0.2009.12.03.15.41.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 15:41:37 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B184CAE.3020402@jacaranda.org> Date: Thu, 03 Dec 2009 23:41:34 +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: <61840634-EA19-470F-A77A-2494F493DE85@lurchi.franken.de> <4B14098A.9090801@extendedsubset.com> <20091130182931.39B596C3EB8@kilo.networkresonance.com> <6b9359640911301031o435c8ae9w93ffffb8ac04353a@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB9114E346039C44DE37CD6CB" 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: Thu, 03 Dec 2009 23:41:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB9114E346039C44DE37CD6CB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tolga Acar wrote: > I looked at DTLS and it doesn't seem like it is vulnerable as TLS is. > The "uint16 epoch" and "uint48 sequence_number" in the record header ar= e > input to the MAC and are validated per RFC4347 Section 4.1.2.1. It seem= s > to me that a MiTM would not have a matching epoch+sequence number, the= > MiTM can't change them (ok, may change, but MAC would not validate), an= d > it takes 2^48 for them to roll over. So, short of 2^48 bit rollover (an= d, > don't forget the message sequence number inside the record), I= > don't see how MiTM would work in DTLS. RFC 4347 section 4.1: # As with TLS, the sequence number is set to zero after each # ChangeCipherSpec message is sent. So there are two ways to apply the attack to DTLS: either using the third attack scenario described in : # 3. Two independent TLS sessions Client<->MitM and MitM<->Server # are spliced into one single TLS session Client<->Server through # TLS renegotiation where the MitM proxies all communication or by a rollover of the epoch, which is only 16 bits. The latter is straightforward if the target implementation does not detect rollovers. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB9114E346039C44DE37CD6CB 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/ iF4EAREIAAYFAksYTLQACgkQWUc8YzyzqAcO2wD+Pl5GEPPkhkWAtHWI7j97k1vi xjKwwYfljSqrCld5jcIA/A2VAFhP63Wr/f2tz4oWbQqvS7RGzQzhqzZ93qr2rMDa =dzoQ -----END PGP SIGNATURE----- --------------enigB9114E346039C44DE37CD6CB-- From Nicolas.Williams@sun.com Thu Dec 3 15:51: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 08C4C3A68DF for ; Thu, 3 Dec 2009 15:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Dk8380G6qX for ; Thu, 3 Dec 2009 15:51:21 -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 5498E3A6836 for ; Thu, 3 Dec 2009 15:51:20 -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 nB3NpBeq010802 for ; Thu, 3 Dec 2009 23:51: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 nB3NpBjo022165 for ; Thu, 3 Dec 2009 16:51: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 nB3NdQuJ009368; Thu, 3 Dec 2009 17:39:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB3NdPxD009367; Thu, 3 Dec 2009 17:39:25 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Dec 2009 17:39:25 -0600 From: Nicolas Williams To: Badra Message-ID: <20091203233925.GJ773@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] TLS Renegotiation Indication by adding some meaning to radom values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2009 23:51:22 -0000 > Subject: Re: [TLS] TLS Renegotiation Indication by adding some meaning to radom values If there are any other, better options, then IMO: no way, no, no, never :) So far I think there are better ways. Nico -- From james@manger.com.au Thu Dec 3 16:10: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 5E2253A681B for ; Thu, 3 Dec 2009 16:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=1.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 qYJCLxPrESn4 for ; Thu, 3 Dec 2009 16:10:20 -0800 (PST) Received: from nschwmtas02p.mx.bigpond.com (nschwmtas02p.mx.bigpond.com [61.9.189.140]) by core3.amsl.com (Postfix) with ESMTP id 151743A6836 for ; Thu, 3 Dec 2009 16:10:19 -0800 (PST) Received: from nschwotgx02p.mx.bigpond.com ([58.175.155.56]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20091204001010.XMCI2264.nschwmtas02p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Fri, 4 Dec 2009 00:10:10 +0000 Received: from [192.168.0.2] (really [58.175.155.56]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20091204001009.IXLM19767.nschwotgx02p.mx.bigpond.com@[192.168.0.2]>; Fri, 4 Dec 2009 00:10:09 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: James Manger In-Reply-To: <4B18096E.20805@extendedsubset.com> Date: Fri, 4 Dec 2009 11:10:09 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B17C2F9.9010802@extendedsubset.com> <4B18096E.20805@extendedsubset.com> To: Bodo Moeller , "tls@ietf.org Working Group" , Marsh Ray X-Mailer: Apple Mail (2.1077) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4B185362.0063,ss=1,fgs=0 Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 00:10:21 -0000 I had a quick look at the Java API for TLS and HTTPS to judge how = "typical" applications might cope with changing peer certificates from = TLS renegotiations. The javax.net.ssl.HttpsURLConnection class includes the following = methods: getPeerPrincipal() getServerCertificates() getInputStream() Consider a client written in Java that: 1. makes an HTTPS connection; 2. extracts the server's authenticated name; 3. reads secured content; 4. displays the server's name on a green or white background, depending = on whether or not Extended Validation occurred. 1. HttpsURLConnection https =3D (HttpsURLConnection) = url.openConnection(); 2. serverName =3D https.getPeerPrincipal().getName(); 3. in =3D https.getInputStream(); in.read()... 4. colour =3D isEVCertificate(https.getServerCertificates()[0]) ? green: = white; Unfortunately this is insecure. If a TLS renegotiation completed between steps 2 & 4 then the serverName = may have come from a different certificate than the one whose Extended = Validation status was checked. An attacker defeats a weak domain-validation (DV) process to get a cert = for paypal.com; and gets an extended-validation cert for Attacker Corp. = Now the attacker can fool the client's user: initially negotiating with = the DV cert then renegotiating with the EV cert. The client indicates to = its user that paypal.com was strongly identified -- which is wrong. This example is a little contrived, but I don't think the vulnerability = in the code would be obvious to even a security-aware programmer. The fact that calls to getServerCertificates() and getPeerPrincipal(), = or multiple calls to either of these methods, can return different = identity information each time is highly likely to surprise app = developers -- which is a recipe for vulnerabilities. TLS libraries ensuring that any authenticated peer identity does not = change across renegotiations -- unless the app has explicitly indicated = it is expecting this -- should be a requirement. P.S. Java's HttpsURLConnection often uses a default HostnameVerifier = that probably mitigates the specific example above, but not minor = variations. --=20 James Manger (Telstra)= From djhopwood@googlemail.com Thu Dec 3 16:30: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 667FA3A67F8 for ; Thu, 3 Dec 2009 16:30:16 -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 hQ5tZUqrVPSU for ; Thu, 3 Dec 2009 16:30:15 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id ECC793A67B7 for ; Thu, 3 Dec 2009 16:30:13 -0800 (PST) Received: by ewy8 with SMTP id 8so2263897ewy.15 for ; Thu, 03 Dec 2009 16:30: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=e79hqp9V9aXPX52v2Dtc5lkxDqm+q3hLW/oLrFvUDyc=; b=PYiDe7VLvwXz8yE4O2uFlILRJq0IhfVQt7RBnsPdDxgzF0npw7tMh544dW6eOBiP2N nieMsd3uGsCzuxGSsFcPQEW21espKwJUofU84s3sYHLfmQQ6ClATT79wnLl6I9wOYQDv FfHtBoSYJqhAoCT9VIIaWngtNCer0f3ODTyrc= 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=CNNNi7APCaqK7VftSMsZKj6IeWtK06x55/9ql2LaYmn/UY+aZ1WF6TZ5BXB+ey1zPb 1IiG2YNfOpl8Dt52Tbw8RV+Wru5Z5wmh++QZmVKdJQJk82l2sXy/LymnYvqFsCLaXV52 95r8JB7VniKL6D6c9/8NTT/YO75ZrOnQ06zEo= Received: by 10.216.86.7 with SMTP id v7mr760843wee.203.1259886602072; Thu, 03 Dec 2009 16:30:02 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 28sm8690683eye.7.2009.12.03.16.30.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 16:30:01 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B185802.6070306@jacaranda.org> Date: Fri, 04 Dec 2009 00:29:54 +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: <4B17C2F9.9010802@extendedsubset.com> <4B18096E.20805@extendedsubset.com> In-Reply-To: <4B18096E.20805@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig91405FED3574A8A58D2B8257" Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 00:30:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91405FED3574A8A58D2B8257 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > * The TLS protocol allows application data to be interleaved within > rengotiation handshake messages. Sometimes this is desired, but may > require extra care. The application-supplied callback and TLS library > normally SHOULD discard any buffered plaintext at the point of > renegotiation. I appreciate the problem that this recommendation is trying to solve, but as stated here it may do more harm than good. Discarding any plaintex= t may cause the application protocol states at the client and server to lose synchronization, creating a vulnerability, or at least incorrect behaviour. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig91405FED3574A8A58D2B8257 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/ iF4EAREIAAYFAksYWAoACgkQWUc8YzyzqAdwuQD+IBVkz8+8mssMXZohJKTceXTi 8VC+NcVxkDN2JyfYxGwBAJpLHwyPgGW35SRkFjpXKggit+yIYtTCi8Y/SkryKsuD =fEed -----END PGP SIGNATURE----- --------------enig91405FED3574A8A58D2B8257-- From marsh@extendedsubset.com Thu Dec 3 16:32: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 3C5593A6884 for ; Thu, 3 Dec 2009 16:32:23 -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 BYiExDPmqLe3 for ; Thu, 3 Dec 2009 16:32: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 0758A3A684C for ; Thu, 3 Dec 2009 16:32: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 1NGM5l-000L2I-1Y; Fri, 04 Dec 2009 00:32:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EB0DB603C; Fri, 4 Dec 2009 00:32: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: U2FsdGVkX193C2BMP+ThAv4N+H/re5TPEKTJXvmWkRc= Message-ID: <4B185888.2090903@extendedsubset.com> Date: Thu, 03 Dec 2009 18:32:08 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: James Manger References: <4B17C2F9.9010802@extendedsubset.com> <4B18096E.20805@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org Working Group" Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 00:32:23 -0000 James Manger wrote: > > 1. HttpsURLConnection https = (HttpsURLConnection) > url.openConnection(); 2. serverName = > https.getPeerPrincipal().getName(); 3. in = https.getInputStream(); > in.read()... 4. colour = > isEVCertificate(https.getServerCertificates()[0]) ? green: white; > > Unfortunately this is insecure. Yep. > If a TLS renegotiation completed between steps 2 & 4 then the > serverName may have come from a different certificate than the one > whose Extended Validation status was checked. Yep. > An attacker defeats a weak domain-validation (DV) process to get a > cert for paypal.com; and gets an extended-validation cert for > Attacker Corp. Now the attacker can fool the client's user: initially > negotiating with the DV cert then renegotiating with the EV cert. The > client indicates to its user that paypal.com was strongly identified > -- which is wrong. Or he may even be able to start with an EV cert for "evil.example.com". > This example is a little contrived, but I don't think the > vulnerability in the code would be obvious to even a security-aware > programmer. It is usually how example code is shown, especially for scripting languages. > The fact that calls to getServerCertificates() and > getPeerPrincipal(), or multiple calls to either of these methods, can > return different identity information each time is highly likely to > surprise app developers -- which is a recipe for vulnerabilities. > > TLS libraries ensuring that any authenticated peer identity does not > change across renegotiations -- unless the app has explicitly > indicated it is expecting this -- should be a requirement. It's completely fixed by draft-ietf-tls-renegotiation, no additional constraints on the certs are necessary. > P.S. Java's HttpsURLConnection often uses a default HostnameVerifier > that probably mitigates the specific example above, but not minor > variations. Yep. - Marsh From marsh@extendedsubset.com Thu Dec 3 16: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 F00493A6804 for ; Thu, 3 Dec 2009 16:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 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 CGFxpYHMKYny for ; Thu, 3 Dec 2009 16:34:53 -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 466AA3A67D4 for ; Thu, 3 Dec 2009 16:34:53 -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 1NGM8C-000Lzk-Gz; Fri, 04 Dec 2009 00:34:44 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E51B1603C; Fri, 4 Dec 2009 00:34:43 +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+qOXeXYUjB944MyDZtEDDnl3mMW3mYSw0= Message-ID: <4B185921.5040106@extendedsubset.com> Date: Thu, 03 Dec 2009 18:34:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood References: <4B17C2F9.9010802@extendedsubset.com> <4B18096E.20805@extendedsubset.com> <4B185802.6070306@jacaranda.org> In-Reply-To: <4B185802.6070306@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] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 00:34:54 -0000 David-Sarah Hopwood wrote: > Marsh Ray wrote: >> * The TLS protocol allows application data to be interleaved within >> rengotiation handshake messages. Sometimes this is desired, but may >> require extra care. The application-supplied callback and TLS library >> normally SHOULD discard any buffered plaintext at the point of >> renegotiation. > > I appreciate the problem that this recommendation is trying to solve, > but as stated here it may do more harm than good. Discarding any plaintext > may cause the application protocol states at the client and server to > lose synchronization, creating a vulnerability, or at least incorrect > behaviour. Good point. It certainly "requires extra care". Ideally the app layer would be defined to discard all state and buffered data at the point of renegotiation, too. - Marsh From mickgray@au1.ibm.com Thu Dec 3 16:36: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 9D0833A67D4 for ; Thu, 3 Dec 2009 16:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 JwdTRz6t7mkX for ; Thu, 3 Dec 2009 16:36:13 -0800 (PST) Received: from e23smtp07.au.ibm.com (e23smtp07.au.ibm.com [202.81.31.140]) by core3.amsl.com (Postfix) with ESMTP id B43AB3A67B7 for ; Thu, 3 Dec 2009 16:36:12 -0800 (PST) Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp07.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB40a2Ur001591 for ; Fri, 4 Dec 2009 11:36:02 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB40WOv41638438 for ; Fri, 4 Dec 2009 11:32:24 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB40a2VF024228 for ; Fri, 4 Dec 2009 11:36:02 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB40a21I024215; Fri, 4 Dec 2009 11:36:02 +1100 In-Reply-To: To: James Manger X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Fri, 4 Dec 2009 10:35:43 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 04/12/2009 11:42:57 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 00:36:13 -0000 James Manger wrote: > TLS libraries ensuring that any authenticated peer identity does not > change across renegotiations -- unless the app has explicitly > indicated it is expecting this -- should be a requirement. +1 - Mick Gray > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Thu Dec 3 16:52: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 098413A6804 for ; Thu, 3 Dec 2009 16:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 L1FOFVeOY3Un for ; Thu, 3 Dec 2009 16:52: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 E9AEA3A67B7 for ; Thu, 3 Dec 2009 16:52:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB40qBBH015824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 01:52:11 +0100 (MET) From: Martin Rex Message-Id: <200912040052.nB40qAq8025552@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 4 Dec 2009 01:52:10 +0100 (MET) In-Reply-To: <4B185888.2090903@extendedsubset.com> from "Marsh Ray" at Dec 3, 9 06:32:08 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, james@manger.com.au Subject: Re: [TLS] matching identity, by default 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, 04 Dec 2009 00:52:25 -0000 Marsh Ray wrote: > > > The fact that calls to getServerCertificates() and > > getPeerPrincipal(), or multiple calls to either of these methods, can > > return different identity information each time is highly likely to > > surprise app developers -- which is a recipe for vulnerabilities. > > > > TLS libraries ensuring that any authenticated peer identity does not > > change across renegotiations -- unless the app has explicitly > > indicated it is expecting this -- should be a requirement. > > It's completely fixed by draft-ietf-tls-renegotiation, no additional > constraints on the certs are necessary. That is a pretty bold statement and doesn't match the question. Unless you and Nasko have made a U-turn on your position about "lockdown of established identities during renegotiation", the change of the certificate will continue to be possible, and therefore "can return different identity information each time" remains valid. The TLS renegotiation vulnerability allowed to pass along the TLS endpoint during renegotiation freely, an in particular to unsuspecting TLS peers. The secure renegotiation will ensure that the endpoint of a renegotiated TLS session will be tied securely to the endpoints of the enclosing TLS session. And if one does _not_ use any of the plain RSA ciphersuites (but instead the DHE ones), then even an attacker in possession of the server's long term credential (like a disgruntled admin) will not be able to manipulate the renegotiation and get someone else to authenticate injected requests. What the renegotiation fix also not fixes is any potential security vulnerabilites from the interleaving of application data during the renegotiation handshake. -Martin From mrex@sap.com Thu Dec 3 17:04: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 53E303A6403 for ; Thu, 3 Dec 2009 17:04:42 -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 C6U8AQabmIie for ; Thu, 3 Dec 2009 17:04: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 319903A67F6 for ; Thu, 3 Dec 2009 17:04:41 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB414SHj013244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 02:04:28 +0100 (MET) From: Martin Rex Message-Id: <200912040104.nB414SS9026332@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 4 Dec 2009 02:04:28 +0100 (MET) In-Reply-To: <4B185921.5040106@extendedsubset.com> from "Marsh Ray" at Dec 3, 9 06:34: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] matching identity, by default 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, 04 Dec 2009 01:04:42 -0000 Marsh Ray wrote: > > David-Sarah Hopwood wrote: > > Marsh Ray wrote: > >> * The TLS protocol allows application data to be interleaved within > >> rengotiation handshake messages. Sometimes this is desired, but may > >> require extra care. The application-supplied callback and TLS library > >> normally SHOULD discard any buffered plaintext at the point of > >> renegotiation. > > > > I appreciate the problem that this recommendation is trying to solve, > > but as stated here it may do more harm than good. Discarding any plaintext > > may cause the application protocol states at the client and server to > > lose synchronization, creating a vulnerability, or at least incorrect > > behaviour. > > Good point. It certainly "requires extra care". > > Ideally the app layer would be defined to discard all state and buffered > data at the point of renegotiation, too. When previously established identities are locked down, secure renegotiation is used, and newly established identites during renegotiation are _not_ made available before the renegotiation handshake has successfully completed, then there is no need to discard any buffers or prohibit the interleaving of application data with the renegotiation. There is probably no "one size fits all" semantics, maybe we need several different semantics "profiles" among which an application can chose: 1) allow arbitrary changes of identites during renegotiation, but prohibit any transfer of application data during the renegotiation handshake, 2) lock down previously established identities during renegotiation and do not make newly established identities available to app before the renegotiation has successfully completed. 3) renegotiation completely disabled 4) your favourite ... -Martin From djhopwood@googlemail.com Thu Dec 3 17: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 B60D93A691B for ; Thu, 3 Dec 2009 17:08:35 -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 YaXsX49wIUlN for ; Thu, 3 Dec 2009 17:08: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 591373A6403 for ; Thu, 3 Dec 2009 17:08:34 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so458967eyf.51 for ; Thu, 03 Dec 2009 17:08:21 -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=54a074x27iFyJI4m0cfxDcH2y6WnOGRl/JnFn/miRCE=; b=jHMErwi4D0b6E1fA6Ir0CX7MJhpL3gwztbxGTcUDAfTINwdj/o2J2oRnamwfIyVfSa aDTtsqEkq4lVKh30NGcdIDTgZg+Dd/gyJnK5Fu+rtBnFDLa6Fxw5nBew7jvL3H9aXCKv v86qCsPvNLr1yjbM57Y9R8Y5xJ1J0eZ3B2BUQ= 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=mgc6H791sD2zxZ80Skz+vQdd87DtTxWCCoY8UzaBtycHxW2Tqy2Yfm0Yk4zqd2PeZJ cql7S87OjgaZ/y+sacfOC7WpJurZsiTxv2IePvrLCYLWtCGlCUVzJMeWgmEMxApBm01x M0fMx6FpPGBMqC30K/7gZ72dt0cQTptpSWmRg= Received: by 10.213.102.138 with SMTP id g10mr2492172ebo.19.1259888901719; Thu, 03 Dec 2009 17:08:21 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm1626774ewy.9.2009.12.03.17.08.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 17:08:20 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1860F6.6070900@jacaranda.org> Date: Fri, 04 Dec 2009 01:08: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: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B1824F7.709@extendedsubset.com> In-Reply-To: <4B1824F7.709@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1A9E9884E447C8BC2BECAFC6" Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 01:08:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1A9E9884E447C8BC2BECAFC6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > Martin Rex wrote: >> Marsh Ray wrote: >>> Modern browsers are sending the SNI extension, no need for the hack >>> there. Let them use the MCSV only for the (sigh) fall-back logic. >> >> Do you really want to punish _ALL_ the extensions-tolerant Servers=20 >> that do not implement TLS extensions so far for being >> extensions-tolerant? Sounds like a pretty bad idea to me. >=20 > What are you talking about? >=20 >> If you don't require the MCSV on all ClientHellos, then all >> extension-tolerant servers must implement TLS extensions in order >> to wade through the extensions sent by clients >=20 > Yes, they would need to parse the extensions rather than ignore them. > It's a 4 line 'for' loop, big deal. They don't have to add full suppor= t > for generic extension handling to their API to do this. >=20 >> in order to find >> an empty TLS extension RI or one that contains verify_data >> from a Client.Finished message. >=20 > There's no other way to supply verify_data. On the contrary, Martin's draft supplies verify_data to the Finished computation without putting it in an extension. FWIW, I don't understand Martin's argument about "punishing" extension-tolerant servers either. The reason to have only one C->S signalling mechanism (regardless of which draft is adopted) is much simpler than that: fewer cases =3D> simpler protocol and less to go wrong= =2E No moral judgements of server implementors are required or relevant here.= --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig1A9E9884E447C8BC2BECAFC6 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/ iF4EAREIAAYFAksYYQUACgkQWUc8YzyzqAe7EgEAllrqmxNeiOIg0xnSmkgg6xQ+ gFJ78dEtPQUPBeuvP7IA/jEOTmvROi5y99amxDsRPABqkMrnvfauGTAVa8kxZQFQ =e5n5 -----END PGP SIGNATURE----- --------------enig1A9E9884E447C8BC2BECAFC6-- From marsh@extendedsubset.com Thu Dec 3 17:12: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 78C203A6933 for ; Thu, 3 Dec 2009 17:12:18 -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 mkyCgQcgcLS0 for ; Thu, 3 Dec 2009 17:12:17 -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 825753A692E for ; Thu, 3 Dec 2009 17:12:16 -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 1NGMiN-000EqT-Kn; Fri, 04 Dec 2009 01:12:07 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0CA4B603C; Fri, 4 Dec 2009 01:12: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+exVV5HOlju5kLZGNrH1+Bbke5ItDzlVI= Message-ID: <4B1861E1.90204@extendedsubset.com> Date: Thu, 03 Dec 2009 19:12:01 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912040052.nB40qAq8025552@fs4113.wdf.sap.corp> In-Reply-To: <200912040052.nB40qAq8025552@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, james@manger.com.au Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 01:12:18 -0000 Martin Rex wrote: > Marsh Ray wrote: >>> The fact that calls to getServerCertificates() and >>> getPeerPrincipal(), or multiple calls to either of these methods, can >>> return different identity information each time is highly likely to >>> surprise app developers -- which is a recipe for vulnerabilities. >>> >>> TLS libraries ensuring that any authenticated peer identity does not >>> change across renegotiations -- unless the app has explicitly >>> indicated it is expecting this -- should be a requirement. >> It's completely fixed by draft-ietf-tls-renegotiation, no additional >> constraints on the certs are necessary. > > That is a pretty bold statement and doesn't match the question. > > Unless you and Nasko have made a U-turn on your position about "lockdown > of established identities during renegotiation", the change of > the certificate will continue to be possible, and therefore > "can return different identity information each time" remains valid. Yes, it will be possible for authentication credentials/certificates to change. That's one of the primary purposes of renegotiation. No, it will not be possible for a MitM or other network-level attacker to coordinate the change. > The TLS renegotiation vulnerability allowed to pass along the > TLS endpoint during renegotiation freely, an in particular to > unsuspecting TLS peers. > > The secure renegotiation will ensure that the endpoint of > a renegotiated TLS session will be tied securely to the > endpoints of the enclosing TLS session. It ensures continuity-of-identity of the client and server across all the [unnamed things between handshakes] on the connection. This is not the same as saying the certificates never change, but it restores the missing and essential property that everyone thought they were getting when they made a connection with the "secure sockets layer" protocol. In a sense, it takes the authentication which is currently per-session and makes it cumulative across the entire connection. Applications may not treat it that way, but at least one important case (HTTPS) does. > And if one does _not_ use any of the plain RSA ciphersuites (but instead > the DHE ones), then even an attacker in possession of the > server's long term credential (like a disgruntled admin) > will not be able to manipulate the renegotiation and get someone > else to authenticate injected requests. Someone in possession of an RSA private key can do anything that cert represents except decrypt a previously-captured DH session. It's debatable whether or not this is even an "attack" since he has the primary (and usually only) credentials. > What the renegotiation fix also not fixes is any potential > security vulnerabilites from the interleaving of > application data during the renegotiation handshake. Yes, but I suspect that those attacks are greatly mitigated by preventing a MitM from monkeying around with the renegotiation in the first place. - Marsh From marsh@extendedsubset.com Thu Dec 3 17:26: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 87D993A6977 for ; Thu, 3 Dec 2009 17:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSNXNdQfB21B for ; Thu, 3 Dec 2009 17:26: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 BDCB33A6403 for ; Thu, 3 Dec 2009 17:26: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 1NGMwO-000JzA-W3; Fri, 04 Dec 2009 01:26:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C65A0603C; Fri, 4 Dec 2009 01:26: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: U2FsdGVkX18dJGvIsvOI8P1sQS9EbGOdvTqbSEVkNPg= Message-ID: <4B186549.7040402@extendedsubset.com> Date: Thu, 03 Dec 2009 19:26:33 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood References: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B1824F7.709@extendedsubset.com> <4B1860F6.6070900@jacaranda.org> In-Reply-To: <4B1860F6.6070900@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] Last Call: 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, 04 Dec 2009 01:26:46 -0000 David-Sarah Hopwood wrote: > Marsh Ray wrote: >> There's no other way to supply verify_data. > > On the contrary, Martin's draft supplies verify_data to the Finished > computation without putting it in an extension. Good point, I should have said what I meant "... explicitly across the wire." Martin's proposal has many things to like about it, but I was treating that as a separate discussion. > FWIW, I don't understand Martin's argument about "punishing" > extension-tolerant servers either. The reason to have only one C->S > signalling mechanism (regardless of which draft is adopted) is much > simpler than that: fewer cases => simpler protocol and less to go wrong. I won't argue with that, that is definitely an important consideration. But keep in mind, the spec still needs to deal with all cases! It can say "producers of this protocol element MUST set A and not B", but it still has to document what happens if it doesn't! E.g., "Consumers MUST check for and handle the case where A is not set by alert/terminating. Consumers MUST also check for and handle the case where B is set by blah blah blah." A conscientious implementor will test these cases explicitly. We can be sure that "freelance security researchers" will be "validating" the implementations, too. > No moral judgements of server implementors are required or relevant here. It is hard to resist though. :-) - Marsh From mrex@sap.com Thu Dec 3 17:54: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 B75A03A6842 for ; Thu, 3 Dec 2009 17:54:31 -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 1UubjUgJxjSY for ; Thu, 3 Dec 2009 17:54: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 9A8263A67B4 for ; Thu, 3 Dec 2009 17:54:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB41sJOj027647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 02:54:19 +0100 (MET) From: Martin Rex Message-Id: <200912040154.nB41sIt2029221@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 4 Dec 2009 02:54:18 +0100 (MET) In-Reply-To: <4B1861E1.90204@extendedsubset.com> from "Marsh Ray" at Dec 3, 9 07:12: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, james@manger.com.au Subject: Re: [TLS] matching identity, by default 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, 04 Dec 2009 01:54:31 -0000 Marsh Ray wrote: > > > The TLS renegotiation vulnerability allowed to pass along the > > TLS endpoint during renegotiation freely, an in particular to > > unsuspecting TLS peers. > > > > The secure renegotiation will ensure that the endpoint of > > a renegotiated TLS session will be tied securely to the > > endpoints of the enclosing TLS session. > > Yes, it will be possible for authentication credentials/certificates to > change. That's one of the primary purposes of renegotiation. > > It ensures continuity-of-identity of the client and server across all > the [unnamed things between handshakes] on the connection. I'm sorry, but these two things are mutually exclusive. The TLS renegotiation fix addresses only the TLS endpoint thing, it does absolutely nothing about the identities. continuity-of-identity is _ONLY_ possible if you lock down the certificates of the peers during renegotiation. That is _not_ part of the TLS renegotiation fix. Any notion of identity related to attributes in the certificate that was used to carry the public key around is out-of-scope for TLS. Two certs that differ in at least one bit refer to seperate identies, as far as TLS is concerned. It may be that an application considers a Server certificate for CN=www.foo.com issued by VeriSign and another one with the same CN=www.foo.com issued by GlobalSign to be interchangeable, but they _DEFINITELY_ are completely different identities. If you have an end user cert and a renewed end user cert (same public key, same CA, but different validity), then these might refer to the same Identity in your PKI, but for TLS these are definitely distinct identities. -Martin From djhopwood@googlemail.com Thu Dec 3 18: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 3FF403A6863 for ; Thu, 3 Dec 2009 18:28:11 -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 aq-7swdLiVAO for ; Thu, 3 Dec 2009 18:28:10 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 201B93A6403 for ; Thu, 3 Dec 2009 18:28:09 -0800 (PST) Received: by ewy8 with SMTP id 8so2354659ewy.15 for ; Thu, 03 Dec 2009 18:27: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=bbJ3dP6zCQh/cToNVDM5AeDMJqCQHcola/gtXKcgM28=; b=b9IwMqcf+UtRLsVNDCQBFUUO0ecB0JT5oTr7+mlJLaIii0KD4g12WQy+QLNIOlGuIu IInTaRsu6dFo6yB2iI72ZWOhK8sgcvwDPmEBF8Ylvy6GMnwqf7aiIWzxMlsHzqwcpsQk zdQKf3hk8EohLuiUcBBa1AP0h8P+EqR2bLFns= 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=JvpAkfVhLFFM5K7HVCxLJanONxQWGuApA9gwIvBUfWaBsv70Jy1tA0Cy7YU41Jp+KH wCaoM0mV/qVrZay+mMHoIbJLHZGI5ATy0S1u+uA0p6Lf8KyBbo0hlgxb+LQ/2Yx7Yr4e wSzIa1xINFyR7XupuMHDvtRx6qu+KUcT0nQig= Received: by 10.213.103.130 with SMTP id k2mr2579340ebo.61.1259893678052; Thu, 03 Dec 2009 18:27:58 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm1645285ewy.8.2009.12.03.18.27.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 18:27:57 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1873A3.7060900@jacaranda.org> Date: Fri, 04 Dec 2009 02:27: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: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B18314E.3000002@pobox.com> In-Reply-To: <4B18314E.3000002@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig0E7B92A31D9998B4C942DA79" Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 02:28:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0E7B92A31D9998B4C942DA79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > Wan-Teh Chang wrote: >> >> We can do what Chris Newman suggested -- require that the >> RI extension be listed first in ClientHellos -- so that servers >> don't need to wade through the extensions to find RI. >=20 > I think that the most we can/should do is RECOMMEND that the RI > extension be first in the list. I don't see the point. Correct implementations would have to check the whole list anyway (and any performance benefit of the RI extension being first is negligable). As others have pointed out, looping through extensions is trivial; using language such as "wading through" misrepresents its complexity. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig0E7B92A31D9998B4C942DA79 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/ iF4EAREIAAYFAksYc60ACgkQWUc8YzyzqAelnAD9Fil9LDb1R5xsxq+Sd1AoTKm4 K3LvizX/AcbyKwV4y8UA/RA152U4rI3bBoxuyv4MsijESuZQOZY4H/OkQdHAYClN =yPaF -----END PGP SIGNATURE----- --------------enig0E7B92A31D9998B4C942DA79-- From mrex@sap.com Thu Dec 3 18:37: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 091DA3A680B for ; Thu, 3 Dec 2009 18:37:22 -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 8NiXOvI+zRgB for ; Thu, 3 Dec 2009 18:37: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 F28BC3A6842 for ; Thu, 3 Dec 2009 18:37:20 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB42bBGN013291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 03:37:11 +0100 (MET) From: Martin Rex Message-Id: <200912040237.nB42bAYk001929@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Fri, 4 Dec 2009 03:37:10 +0100 (MET) In-Reply-To: <4B1860F6.6070900@jacaranda.org> from "David-Sarah Hopwood" at Dec 4, 9 01:08:06 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] Last Call: 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: Fri, 04 Dec 2009 02:37:22 -0000 David-Sarah Hopwood wrote: > > FWIW, I don't understand Martin's argument about "punishing" > extension-tolerant servers either. The reason to have only one C->S > signalling mechanism (regardless of which draft is adopted) is much > simpler than that: fewer cases => simpler protocol and less to go wrong. > No moral judgements of server implementors are required or relevant here. It's about who will have to add/change how much code. The installed base looks like this: Clients: 1. client. no extensions, no renego 2. client. no extensions, with renego 3. client with extensions, no renego 4. client with extensions, with renego Servers: 5. server, extensions-intolerant, no renego 6. server, extensions-intolerant, with renego 7. server, no extensions, no renego 8. server, no extensions, with renego 9. server, with extensions, no renego 10. server, with extensions, with renego Then you have the various interop-scenarios between clients and servers and the three attack scenarios that you want to recognize and abort (some of which don't apply if one or both sides do not support renego) a. clients initial handshake is proxied into servers renegotiation b. clients renegotiation is proxied into servers initial handshake c. clients renegotiation is proxied into servers renegotiation The question now is: what are the minimum amount of changes that each of the 1-10 types in the installed base will have to make in order to implement TLS extension RI. The question whether or not MCSV is mandatory to use for ClientHello has an impact on the amount of code some of these have to implement. >From the servers (5) has the least amount of work if it remains extensions-intolerant. (7) has much more than (5) work if there is no MUST send MCSV. End result: (5) has a significant _negative_ incentive to become an updated (7). And (7) has an incentive to become an updated (5) if we do not mandate MCSV. -Martin From djhopwood@googlemail.com Thu Dec 3 18:37: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 3E5083A6904 for ; Thu, 3 Dec 2009 18:37:30 -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 V4LV7LhiKxzE for ; Thu, 3 Dec 2009 18:37:29 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 155893A68E8 for ; Thu, 3 Dec 2009 18:37:28 -0800 (PST) Received: by ewy8 with SMTP id 8so2361071ewy.15 for ; Thu, 03 Dec 2009 18:37:17 -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=g+pfBPYMT6Jgq0NqrHM6wvFVlvSUPDtN6h/BKW1yljY=; b=V3jyg0fs21y0vh6nKLJ0dqtfM6iUth4Q1HFqE/KY2wvNsFJl7CMAH3DF9rBCat58V5 w0Iu+1e8bpgRK+nMfI7evhneD8Wl3Qf6pKRwDhyzjrfheoGQJqOXsE3B0pHdIGLiO+BR yJ93vSd9UVZuKGY1pwB7yDeItmGAKs/cb2+qg= 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=DSQrIcVXVzI5eGDnccHhiLaQyDhVUf3tbPjBP8AIPnaJc4M56OFWdSNptcr/VVSsVj Kb4CD7T2HORBK3RyvKRH2RWrxgUO7yccEajiARJRu2m0Ax7Aa4s/+CiejtmgDNQ4Dcan kqR08m+zMXI8tTsPnCYLB0ZisDQbBXj/d7Ltg= Received: by 10.213.51.200 with SMTP id e8mr2480109ebg.79.1259894237280; Thu, 03 Dec 2009 18:37:17 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm1650723ewy.5.2009.12.03.18.37.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 18:37:16 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1875D9.60709@jacaranda.org> Date: Fri, 04 Dec 2009 02:37: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: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig18B0B99F9E7F743AA80EFA4F" Subject: [TLS] Overzealous RFC-2119-ification (was Last Call: 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, 04 Dec 2009 02:37:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig18B0B99F9E7F743AA80EFA4F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Badra wrote: > RFC5246: >=20 > When multiple extensions of different types are present in the > ClientHello or ServerHello messages, the extensions MAY appear in a= ny > order. Incidentally, this is an incorrect use of RFC 2119 "MAY". RFCs 3546 and 4366 had it right: # Also note that when multiple extensions of different types are # present in the extended client hello or the extended server hello, # the extensions may appear in any order. There MUST NOT be more than # one extension of the same type. MAY should only be used when "an item is truly optional"; it shouldn't be applied indiscriminately to any case where there is an implementation choice. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig18B0B99F9E7F743AA80EFA4F 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/ iF4EAREIAAYFAksYddoACgkQWUc8YzyzqAewAwEAktXhUUubrcg+bth3lguVPcVo 4qmOWa0XFXTC/GBL3WUA/3wOdMA/OrD3tWVFGuwH/gwpbIzrSpFB0Vz5R5Trigr9 =bzBT -----END PGP SIGNATURE----- --------------enig18B0B99F9E7F743AA80EFA4F-- From djhopwood@googlemail.com Thu Dec 3 18: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 769583A6403 for ; Thu, 3 Dec 2009 18:53:21 -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 d+1ijcMFO0df for ; Thu, 3 Dec 2009 18:53:20 -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 06F313A6872 for ; Thu, 3 Dec 2009 18:53:19 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so1594915eya.5 for ; Thu, 03 Dec 2009 18:53: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=VsthmR4VGXoVzCZPhcGOF+8c8Ed3LuMSZwl6EmnwmJg=; b=RwoNc+I0Zzg1P/AQZbtRtKjqTcYmir7sUruYkMD+BXCdfbsyEpylXhbvem0F/KY/fo q+PFVFsXtNWRvpHxH1AafM6YWC8NXQ0/mLNy+jEZE+V9JbdZQOVqGfSlemYiP1yD3nEs 8ABRyKxz1pZBI3ZC4WJqwePvBkjPR6Lvj/r3M= 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=ritiHQOxQ0XN3t3AtZkeG0CvDVaPidVsT+LGTNdhHiqvc4Zig9cKWOwfhm6Ehixo+J Ay0DqmOgdI+ccmwpnntgcgscwab85iriaqtou5ettK+ADDpz4VwI82WyPUWvUaP+vnd8 M3MWKGzH+Lo3S691nW3Yl8XnO5C9aZMB/Muzo= Received: by 10.213.25.74 with SMTP id y10mr10018974ebb.14.1259895186340; Thu, 03 Dec 2009 18:53:06 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 24sm4758374eyx.22.2009.12.03.18.53.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 18:53:05 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B18796E.8020600@jacaranda.org> Date: Fri, 04 Dec 2009 02:52: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: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B1824F7.709@extendedsubset.com> <4B1860F6.6070900@jacaranda.org> <4B186549.7040402@extendedsubset.com> In-Reply-To: <4B186549.7040402@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBA28FC953CE4477C70C9516F" Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 02:53:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA28FC953CE4477C70C9516F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > David-Sarah Hopwood wrote: >> Marsh Ray wrote: >>> There's no other way to supply verify_data. >> On the contrary, Martin's draft supplies verify_data to the Finished >> computation without putting it in an extension. >=20 > Good point, I should have said what I meant "... explicitly across the > wire." Martin's proposal has many things to like about it, but I was > treating that as a separate discussion. >=20 >> FWIW, I don't understand Martin's argument about "punishing" >> extension-tolerant servers either. The reason to have only one C->S >> signalling mechanism (regardless of which draft is adopted) is much >> simpler than that: fewer cases =3D> simpler protocol and less to go wr= ong. >=20 > I won't argue with that, that is definitely an important consideration.= >=20 > But keep in mind, the spec still needs to deal with all cases! It does, but that doesn't necessarily require implementations to have extra code to handle all cases. For instance, if the spec says "servers MUST ignore a renegotiation_info extension sent in the ClientHello", then= : - servers do not need to include any code to implement that requirement,= since they ignore unknown extensions anyway. - whether the client sends the extension or not on an initial connection= won't have any effect on security (when talking to a correct server, either patched or unpatched), so there is still less to go wrong. >> No moral judgements of server implementors are required or relevant he= re. >=20 > It is hard to resist though. :-) I won't argue with that :-) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigBA28FC953CE4477C70C9516F 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/ iF4EAREIAAYFAksYeY4ACgkQWUc8YzyzqAe17gD+Lws5P9y5hrmBUS0BMKy0pV0H +6M9jsJfIGIgmb7io3oA/RjIeZ3keH+Uh9D4glptHKOejK71yzJtBd/A/Tz7ft8e =U+tM -----END PGP SIGNATURE----- --------------enigBA28FC953CE4477C70C9516F-- From djhopwood@googlemail.com Thu Dec 3 18:58: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 2A48D3A6950 for ; Thu, 3 Dec 2009 18:58:22 -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 s1gRCjQom3OZ for ; Thu, 3 Dec 2009 18:58:21 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 15B583A6403 for ; Thu, 3 Dec 2009 18:58:20 -0800 (PST) Received: by ewy8 with SMTP id 8so2375275ewy.15 for ; Thu, 03 Dec 2009 18:58: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=kEfVG7wrTCv1gViYiiBiN2MA2XZ3kOa9zIyRHo8enaQ=; b=Lb62hBp5/CodszAaGHh6Wd1JTeWjjbZ3AGG9ZhFBlhXiLZouNLIs/cLz2G28YBXpmD zihkkwI+dS5JtwgPTACq6cdAjQxG8ik1ejaxPYl8mDH0xwuYzz2m61ztARZUitCbYvsD 5FrLttmXAaW8UInN7xAR1dFAX1Ost09r8SdD4= 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=GWZCKceHwdOgCc/uJxYmyBcQxqZmwyVp7AWU2J8ITf8Gz2XxYo+GI0+jIPTIIS4Sce iEM0bpyj/OzUbN38BRlY3vN9AWHsz3QuG41sPnkkQB0ZpaFSwsro+3D9ATknFEpwQPiH mqFyWK6x2FiOO8c4ZrSvMRnytVIi4C2hRi59A= Received: by 10.213.110.17 with SMTP id l17mr10030401ebp.18.1259895489630; Thu, 03 Dec 2009 18:58:09 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm1650332ewy.12.2009.12.03.18.58.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 18:58:09 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B187AC0.6040806@jacaranda.org> Date: Fri, 04 Dec 2009 02:58: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: <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B1824F7.709@extendedsubset.com> <4B1860F6.6070900@jacaranda.org> <4B186549.7040402@extendedsubset.com> <4B18796E.8020600@jacaranda.org> In-Reply-To: <4B18796E.8020600@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA7361156B5011460A25FCEFF" Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 02:58:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7361156B5011460A25FCEFF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Marsh Ray wrote: >> But keep in mind, the spec still needs to deal with all cases! >=20 > It does, but that doesn't necessarily require implementations to have > extra code to handle all cases. For instance, if the spec says "servers= > MUST ignore a renegotiation_info extension sent in the ClientHello", I meant, an *initial* renegotiation_info, if we are talking about Eric's draft. (For Martin's draft it would be any renego_protection extension in the ClientHello.) > then: >=20 > - servers do not need to include any code to implement that requiremen= t, > since they ignore unknown extensions anyway. >=20 > - whether the client sends the extension or not on an initial connecti= on > won't have any effect on security (when talking to a correct server,= > either patched or unpatched), so there is still less to go wrong. >=20 >>> No moral judgements of server implementors are required or relevant h= ere. >> It is hard to resist though. :-) >=20 > I won't argue with that :-) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigA7361156B5011460A25FCEFF 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/ iF4EAREIAAYFAksYesAACgkQWUc8YzyzqAc0egD8Cvdzp7df/83QFQE3IkBiNgpT hWy+iilVMVaaVHWHCTIBAIdV3MGe5zccFJi9MJZfLES2yggohyRhJdXOiEyX6/tL =83z0 -----END PGP SIGNATURE----- --------------enigA7361156B5011460A25FCEFF-- From mike-list@pobox.com Thu Dec 3 19:10: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 1E28C3A6999 for ; Thu, 3 Dec 2009 19:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAVQbg5fSBXU for ; Thu, 3 Dec 2009 19:10: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 2DF3F3A6994 for ; Thu, 3 Dec 2009 19:10: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 21F43858F9 for ; Thu, 3 Dec 2009 22:10: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=ll2l/m40HeKd tHBqJ2MVAbzQ5fE=; b=p+9F0I2TOmeMpRCnozBgrGZzFwcmTDI1bAxJZHBRHj9Z 1kMzq0UHD1HOPjU7dZw3/vIA8y5888lPvYkHHgI7sOg+nJnQrclod9icqGrN37aD ZNcPfdS06vx97D7Wcz22Qz1rGzp4a7xAiVQA2OUz51iBF8Qd2FPj0iF6g/j1nLI= 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=HmUv8d tB3E3tZspk2yXx32c/bHwFsWM6vwyL3p0BS1PX7RLyIEnis2E8KAffGYi1272Lq+ UDN2M0fDfSxHqodgh9usMg86NtAUhl1O2WZRS4nOPPQc4W/91+ZkJ7irQCupYn5A XENjv4H3RppQQQu17Le0lGiMnwBeQT5gbqkYA= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1F0EB858F8 for ; Thu, 3 Dec 2009 22:10: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-quonix.pobox.com (Postfix) with ESMTPSA id 535C5858F7 for ; Thu, 3 Dec 2009 22:10:29 -0500 (EST) Message-ID: <4B187DFF.2070708@pobox.com> Date: Thu, 03 Dec 2009 19:11:59 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B18314E.3000002@pobox.com> <4B1873A3.7060900@jacaranda.org> In-Reply-To: <4B1873A3.7060900@jacaranda.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 95C8145E-E082-11DE-A49E-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 03:10:44 -0000 David-Sarah Hopwood wrote: > Michael D'Errico wrote: >> Wan-Teh Chang wrote: >>> We can do what Chris Newman suggested -- require that the >>> RI extension be listed first in ClientHellos -- so that servers >>> don't need to wade through the extensions to find RI. >> I think that the most we can/should do is RECOMMEND that the RI >> extension be first in the list. > > I don't see the point. Correct implementations would have to check > the whole list anyway (and any performance benefit of the RI > extension being first is negligable). > > As others have pointed out, looping through extensions is trivial; > using language such as "wading through" misrepresents its complexity. If someone plans to make a device to detect the RI extension (possibly as part of a firewall or similar), then the closer it is to the front of the list, the less delay will be added to the processing of the connection, and the more connections can be handled per second. We definitely don't want our fix to slow down the establishment of all secure connections by any significant amount. Mike From marsh@extendedsubset.com Thu Dec 3 19:38: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 D55A43A67D4 for ; Thu, 3 Dec 2009 19:38:12 -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 l1hT9QVH0+nr for ; Thu, 3 Dec 2009 19:38:11 -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 7B6DC3A6784 for ; Thu, 3 Dec 2009 19:38:11 -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 1NGOza-0007ct-KB; Fri, 04 Dec 2009 03:38:02 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E59C2603C; Fri, 4 Dec 2009 03:37:57 +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: U2FsdGVkX19y/0SIg+C9eFSpj1+WHZFu2gNM9mzvCaI= Message-ID: <4B188413.2070303@extendedsubset.com> Date: Thu, 03 Dec 2009 21:37:55 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912040154.nB41sIt2029221@fs4113.wdf.sap.corp> In-Reply-To: <200912040154.nB41sIt2029221@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, james@manger.com.au Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 03:38:12 -0000 Martin Rex wrote: > Marsh Ray wrote: >> >> It ensures continuity-of-identity of the client and server across all >> the [unnamed things between handshakes] on the connection. > > I'm sorry, but these two things are mutually exclusive. > The TLS renegotiation fix addresses only the TLS endpoint thing, > it does absolutely nothing about the identities. There's more to identities than certificates. Is there not more to "Martin Rex" than his driver's license? > continuity-of-identity is _ONLY_ possible if you lock down the > certificates of the peers during renegotiation. No, even anon-anon sessions have identity. Why do you think they call it a "session identifier"? Isn't resuming such a session different than establishing a new one? If not, why do you still have to prove you know the master_secret? > That is _not_ > part of the TLS renegotiation fix. In the case of HTTPS client certs for example, an anonymous-client session was established and transferred data. Then the connection was renegotiated to provide a client cert, and the data from the previous session was authenticated retroactively. This was not a design error! It was entirely reasonable for the HTTPS designers who had worked with SSLv2 in the past to expect that SSLv3 would not degrade on any of its basic guarantees, even if the new feature of renegotiation was used. The mistake was that the SSLv3 designers thought that by ensuring continuity-of-encryption (the new handshake is encrypted with the connection state of the old) they were also providing continuity-of-authentication. Or else they thought, like Martin, that an anonymous endpoint had no identity whatsoever, and a certificate-authenticated identity would be re-validated on the handshake. The reality is that that initial "anonymous" session does in fact have a very important identity: he's "the party that sent me the data that I am now authenticating with this client certificate". In order to do this securely, you have to prove that he is the same party as the one now sending you the certificate. In other words, you have to authenticate the anonymous client as being the certified client, and the certified client as being the anonymous client! The way we accomplish this in draft-ietf-tls-renegotiation is by having each side present something in the current connection state that unambiguously states their belief about the previous session state. In this way they cooperate to enforce the continuity-of-authentication, but this only works because both the client and server systems have an interest in seeing that this is done securely. Once our fix reestablishes continuity-of-authentication between connection states, it ensures that the actual party remains the same. It does this regardless of certificates (or lack thereof). This has a dramatic effect: it changes the auth model from independent-authentication-per-connection-state to cumulative-over-entire-connection! In other words, an endpoint could renegotiate an anonymous connection ten times to provide ten different certificates, and the other party can securely treat all data sent over that connection as having been authenticated to all ten certificates! (whatever that means for the specific application protocol) > Any notion of identity related to attributes in the certificate that > was used to carry the public key around is out-of-scope for TLS. > Two certs that differ in at least one bit refer to seperate > identies, as far as TLS is concerned. There's nothing in the TLS spec that says such a thing. > It may be that an application considers a Server certificate for > CN=www.foo.com issued by VeriSign and another one with the > same CN=www.foo.com issued by GlobalSign to be interchangeable, > but they _DEFINITELY_ are completely different identities. I have a driver's license issued by Kansas and a passport issued by the US Dept of State, yet I do not assume two different identities. Sometimes, I am even requested to provide both! They are separate credentials though. Whether or not they are treated as equivalent is extremely context-dependent. > If you have an end user cert and a renewed end user cert > (same public key, same CA, but different validity), then > these might refer to the same Identity in your PKI, but > for TLS these are definitely distinct identities. I have been working in the authentication business for a few years now and have learned a lot. I have seen plenty of subtle bugs and security issues caused by imprecise definitions and mismatching assumptions about identity. There is in fact an entire sub-industry dedicated to "Identity Management Solutions" which makes products for these problems. I'm not saying this to convince you how much I know about it, but to say that I am sure that I don't know much about it at all. Identity is an extremely deep concept with many context-dependent perspectives and opportunities for error. Authentication is a fundamental human activity (and for other animals as well), so most of us are experts in it at some biological level. We also tend to vastly oversimpify issues of identity and underestimate our capacity for error. "Social engineering" is one whole category of examples, the concept of "identity theft" is another. The TLS specs were very wise to defer these issues elsewhere, especially since it deals with a rich mixture of cipher suites and credential types. So riddle me this, Batman: How can someone reading this know that this is the authentic "Marsh Ray" emailing with the authentic "Martin Rex"? In particular, how can we know that you or I were not accidentally switched at the hospital shortly after birth? Do "birth certificates" represent the answer? We should maybe follow this up off-list. - Marsh From marsh@extendedsubset.com Thu Dec 3 21:17: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 3D56D3A68E8 for ; Thu, 3 Dec 2009 21:17:31 -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 dfCRPLZ3gvKZ for ; Thu, 3 Dec 2009 21: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 295623A68F2 for ; Thu, 3 Dec 2009 21: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 1NGQXh-000IIZ-7l; Fri, 04 Dec 2009 05:17:21 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1D5CE603C; Fri, 4 Dec 2009 05:17:20 +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+5tmWJRxgG9CwsTvFMmVwBfkIGzeVi8ho= Message-ID: <4B189B5D.5030907@extendedsubset.com> Date: Thu, 03 Dec 2009 23:17:17 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B18314E.3000002@pobox.com> <4B1873A3.7060900@jacaranda.org> <4B187DFF.2070708@pobox.com> In-Reply-To: <4B187DFF.2070708@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] Last Call: 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, 04 Dec 2009 05:17:31 -0000 Michael D'Errico wrote: > > If someone plans to make a device to detect the RI extension (possibly > as part of a firewall or similar), then the closer it is to the front > of the list, the less delay will be added to the processing of the > connection, and the more connections can be handled per second. We > definitely don't want our fix to slow down the establishment of all > secure connections by any significant amount. We are talking about iterating bits of data that generally comes in over a network, right? Let's say the IETF gets really creative and we end up with of 20 extensions on every Client Hello. The order is well-randomized, so the server has to "wade through" an average of 10 extensions to find the RI. Some of these extensions are really, really big (several KB). So big that for half of them the beginning of the next one hasn't even been fetched into the data cache yet. So it's reasonable to assume that the cost will be predominated by five cold access to slow DRAM at 200ns each. Let's see that comes to... 1 us! Well a microsecond is nothing to sneeze at. During this microsecond many modern CPUs can be processing bits of other connections (that do happen to be in the data cache), so some of that might be hidden in the total throughput. Not to mention that presumably there will be other reasons to "wade through" the extensions like if somebody actually wants to process one for something useful. (For comparison, my modern CPU takes about 18 ms to do an RSA in the handshake, but I know dedicated hardware is much much faster). Well, we don't know how long the device takes to process a handshake without extensions, so it's hard to say what impact randomized ordering will have. We do know from experience that many devices end up being network-bound rather that CPU- or memory-access-bound. It looks like there's a two-byte length for all extensions, which strongly implies that the maximum extension data is 64KB. Let's assume those five memory accesses were over 16KB of data (data that somehow didn't make it into the cache). What speed of network is necessary to be only 10 times slower than us wading through this morass of extensions? 16KB*8/1us/10 ... I get about 13G bit/s. So my rough estimate is that an implementation using a conventional memory architecture could saturate a full-duplex GigE link doing nothing but exchanging hellos loaded-out with extensions and still have 10-100x of headroom. This assumes of course that magic hardware makes all the other calculations instantaneous. To the extent that assumption is false, the overhead of wading through the extensions becomes rapidly even less significant. Now what happens if 90% of implementors take your recommendation and put the RI first in the list every time (for optimum performance of course)? A few things happen: 1. Some development group accidentally writes code that makes an assumption that the ordering is consistent (possibly they aren't native speakers of RFC 2119). 2. A Testing and Verification "QA" department tests their product's interoperability with four different independent implementations. They don't realize that all four took the recommendation on ordering, but others that they didn't test with use some other ordering. 3. Two percent of the servers on the internet end up hanging the connection in a slow failure mode when they get a client hello with sub-optimally ordered extensions. 4. One of the top four major web browsers sends extensions in some arbitrary data-dependent order. The RI extension ends up with about a 33% chance of being first. It takes a minor research effort to figure out why 1.33% of connections end up falling back to extensionless SSLv3. 5. The hello extension mechanism gets a permanent reputation as "not ready to require the use of on the real internet". 6. Consequently, the SNI extension is unsuitable for deployment by shared hosting providers, so every HTTPS site needs its own IP. The world develops an acute shortage of routable IPv4 addresses when Twitbook buys Verisign and convinces everyone that they need a personalized certificate for their page. Everyone switches to IPv6 (ok now it's getting a bit far-fetched). And last but not least: 6. Some big bloated client hello message somewhere gets processed 1 microsecond faster. - Marsh From rms@gnu.org Thu Dec 3 21:30: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 209793A6957 for ; Thu, 3 Dec 2009 21:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.043 X-Spam-Level: X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=1.556, 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 h9CmE+TPoXGr for ; Thu, 3 Dec 2009 21:30:49 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 5B9FC3A6885 for ; Thu, 3 Dec 2009 21:30:49 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NGQkY-0001aG-HI; Fri, 04 Dec 2009 00:30:38 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Marsh Ray In-reply-to: <4B172027.9030200@extendedsubset.com> (message from Marsh Ray on Wed, 02 Dec 2009 20:19:19 -0600) References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> <4B15D9D2.3010107@stpeter.im> <4B15E2DD.3000701@extendedsubset.com> <4B172027.9030200@extendedsubset.com> Message-Id: Date: Fri, 04 Dec 2009 00:30:38 -0500 Cc: tglassey@earthlink.net, 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: 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: Fri, 04 Dec 2009 05:30:50 -0000 It may suit your purposes better for there to be an actual legal confrontation in which you prevail, What in the world are you talking about? You seem to be making an accusation based on a wild leap of imagination. If I wanted to follow the same practice towards you, I could say, It may suit your purposes better to fabricate accusations hoping some of them will stick, But I don't know that is so. Perhaps you did not realize what an extrapolation you were making. So instead of making that accusation, I would like to ask you to think about whether the intentions I have stated suffice to explain my actions. From rms@gnu.org Thu Dec 3 21:30: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 1D2AB3A695F for ; Thu, 3 Dec 2009 21:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, 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 MGfAMfA7VsHL for ; Thu, 3 Dec 2009 21:30:56 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 61C973A695C for ; Thu, 3 Dec 2009 21:30:56 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NGQkh-0001gX-8T; Fri, 04 Dec 2009 00:30:47 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Dean Anderson In-reply-to: (message from Dean Anderson on Thu, 3 Dec 2009 11:23:54 -0500 (EST)) References: Message-Id: Date: Fri, 04 Dec 2009 00:30:47 -0500 Cc: tls@ietf.org, tglassey@earthlink.net, 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: Fri, 04 Dec 2009 05:30:57 -0000 Trademarks could affect a standard if the standard incorporates the trademark in the text. I don't think so. You can write about a Ford car and call it that, without infringing the trademark on Ford. From rms@gnu.org Thu Dec 3 21:31: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 0E08E3A6930 for ; Thu, 3 Dec 2009 21:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.326 X-Spam-Level: X-Spam-Status: No, score=-5.326 tagged_above=-999 required=5 tests=[AWL=1.273, 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 8xqJw3qvomPB for ; Thu, 3 Dec 2009 21:31:13 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id F0B453A68F2 for ; Thu, 3 Dec 2009 21:31:12 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NGQky-0001tA-2q; Fri, 04 Dec 2009 00:31:04 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Marsh Ray In-reply-to: <4B172027.9030200@extendedsubset.com> (message from Marsh Ray on Wed, 02 Dec 2009 20:19:19 -0600) References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> <4B15D9D2.3010107@stpeter.im> <4B15E2DD.3000701@extendedsubset.com> <4B172027.9030200@extendedsubset.com> Message-Id: Date: Fri, 04 Dec 2009 00:31:04 -0500 Cc: tglassey@earthlink.net, 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: 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: Fri, 04 Dec 2009 05:31:20 -0000 http://www.chillingeffects.org/trademark/notice.cgi?NoticeID=203 I will send mail to get a copy of that page. You've missed or ignored my point, which is not about actual law, but about facilitating communication: Sure, but the actual laws are the context and subject matter for this communication. The main purpose of having the disclosure discussion in an open standards effort is to prevent problems later. You want parties to share everything that they think could be relevant, but more importantly they have to not go away thinking that there was something that they weren't obligated to disclose. Sure, but there is no need to raise the issue of laws that can't possibly be relevant. At the same time, why leave out laws that aren't in the list that "intellectual property" supposedly refers to? Using the term "intellectual property" introduces a harmful misunderstanding into any communication. It is worth some effort to choose some other method to achieve the present goal. We could say, "Please tell us about any private privilege you know of which could restrict the distribution or use of systems on account of implementing any part of this specification." And then we could list the known laws believed likely to do so. From rms@gnu.org Thu Dec 3 21:31: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 4C2B03A694E for ; Thu, 3 Dec 2009 21:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.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 SFN8OzdZ05en for ; Thu, 3 Dec 2009 21:31:28 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 8515A3A68F2 for ; Thu, 3 Dec 2009 21:31:28 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NGQlD-00024o-F4; Fri, 04 Dec 2009 00:31:19 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Dean Anderson In-reply-to: (message from Dean Anderson on Thu, 3 Dec 2009 11:23:54 -0500 (EST)) References: Message-Id: Date: Fri, 04 Dec 2009 00:31:19 -0500 Cc: tls@ietf.org, tglassey@earthlink.net, 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: Fri, 04 Dec 2009 05:31:29 -0000 If the IETF wants to ask about laws that might conceivably perhaps be stretched to impose a restriction on use of a protocol, there is no reason to suppose those laws must be among the ones that some call "intellectual property". So instead of limiting the question with that term, it should ask about _any_ legal claim. From djhopwood@googlemail.com Thu Dec 3 21:50: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 74FBC28C0EE for ; Thu, 3 Dec 2009 21:50:30 -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 BKFW90pirYc1 for ; Thu, 3 Dec 2009 21:50:25 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 7B7E428C0EB for ; Thu, 3 Dec 2009 21:50:25 -0800 (PST) Received: by ewy8 with SMTP id 8so2476023ewy.15 for ; Thu, 03 Dec 2009 21:50: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=980F02f6oaMb48ScpiigeA+WhIPNObC95TXeIQ7wUqQ=; b=Nyfi2+HpI/UVk9BjPOrUiQkBtYRtlxCx55gOIV+H9Fll02BP/Qy8AytJJ1Ply717ZD MvDVb1GwZhMwmK/JS0S3TdFXCTTlS2ltC9/G/MC6vRhrkQ6E128Z3/4tipdY0PEkAn9f 0Qg5TVkTmnp8MqTcyYuG7fnWcZ20EEOI3r/8Q= 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=PTsA1lNalWJIjn1ARcjhgnkhHilpJqd6mUKHNED8iXXI3WIRiltjdrMb53yC8ZLUI8 kmbxp5Hx6VNklmPGo3lE3NXOC/BWRjAA0b4TV5LCRCUrjurQbAOVmEQSX8Xg0XIYCLCI dYFscRuLPuWflYPNXd9pnhGIK2Tk4fhed6u2w= Received: by 10.213.110.210 with SMTP id o18mr2811705ebp.13.1259905813772; Thu, 03 Dec 2009 21:50:13 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 16sm1695896ewy.6.2009.12.03.21.50.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 21:50:13 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B18A312.7020903@jacaranda.org> Date: Fri, 04 Dec 2009 05:50: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: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B18314E.3000002@pobox.com> <4B1873A3.7060900@jacaranda.org> <4B187DFF.2070708@pobox.com> In-Reply-To: <4B187DFF.2070708@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFAF3FA86AAD0DAB8DB2D3C70" Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 05:50:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFAF3FA86AAD0DAB8DB2D3C70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > David-Sarah Hopwood wrote: >> Michael D'Errico wrote: >>> Wan-Teh Chang wrote: >>>> We can do what Chris Newman suggested -- require that the >>>> RI extension be listed first in ClientHellos -- so that servers >>>> don't need to wade through the extensions to find RI. >>> I think that the most we can/should do is RECOMMEND that the RI >>> extension be first in the list. >> >> I don't see the point. Correct implementations would have to check >> the whole list anyway (and any performance benefit of the RI >> extension being first is negligable). >> >> As others have pointed out, looping through extensions is trivial; >> using language such as "wading through" misrepresents its complexity. >=20 > If someone plans to make a device to detect the RI extension (possibly > as part of a firewall or similar), then the closer it is to the front > of the list, the less delay will be added to the processing of the > connection, and the more connections can be handled per second. We > definitely don't want our fix to slow down the establishment of all > secure connections by any significant amount. These days it is almost impossible to buy a processor that is wimpy enough that this would add significant latency. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFAF3FA86AAD0DAB8DB2D3C70 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/ iF4EAREIAAYFAksYoxIACgkQWUc8YzyzqAe+wQD9EsIDkxJCATGoIUel1HkBI21J bQL5AEFU2lx8aDbwQ18A+wYqGudpl5YJP0Dis7sQeaL8gHDdyd6vsEsB6t1KQsd9 =fM+m -----END PGP SIGNATURE----- --------------enigFAF3FA86AAD0DAB8DB2D3C70-- From marsh@extendedsubset.com Thu Dec 3 22:07: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 E303B3A681E for ; Thu, 3 Dec 2009 22:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 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 DBVRy9snESKT for ; Thu, 3 Dec 2009 22:07:06 -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 122D93A67D6 for ; Thu, 3 Dec 2009 22:07:06 -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 1NGRJg-0002SR-P0; Fri, 04 Dec 2009 06:06:56 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 21495603C; Fri, 4 Dec 2009 06: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: U2FsdGVkX1/rttFRcex197U/9J1oFDJoClv8YV+a5cE= Message-ID: <4B18A6FC.7000609@extendedsubset.com> Date: Fri, 04 Dec 2009 00:06:52 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rms@gnu.org References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> <4B15D9D2.3010107@stpeter.im> <4B15E2DD.3000701@extendedsubset.com> <4B172027.9030200@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: tglassey@earthlink.net, 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 List-Id: "This is the mailing list 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, 04 Dec 2009 06:07:07 -0000 Richard Stallman wrote: > It may suit your purposes better for there to be an actual legal > confrontation in which you prevail, > > What in the world are you talking about? You seem to be making an > accusation based on a wild leap of imagination. Read it again. It's just analysis, and you're excerpting below the whole-sentence level. > If I wanted to follow the same practice towards you, I could say, > > It may suit your purposes better to fabricate accusations > hoping some of them will stick, > > But I don't know that is so. It's possible, it _may_ be so, but that's true of lots of things we choose not to say. What basis it has is the more interesting discussion. > Perhaps you did not realize what an > extrapolation you were making. I don't think it's so far out. > So instead of making that accusation, I would like to ask you > to think about whether the intentions I have stated suffice > to explain my actions. Listen, I've given these decent hardworking IETF folks way too much to read today already. Here's what I'll do: I apologize if it sounded to you like I was accusing you of something that you didn't want to be accused of. Now we can address the finer points off-list if it's OK with you. - Marsh From james@manger.com.au Fri Dec 4 02:37: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 DACBD3A69DE for ; Fri, 4 Dec 2009 02:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.803, 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 55-GxC2yEeNQ for ; Fri, 4 Dec 2009 02:37:32 -0800 (PST) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by core3.amsl.com (Postfix) with ESMTP id 624D83A67B5 for ; Fri, 4 Dec 2009 02:37:31 -0800 (PST) Received: from nskntotgx01p.mx.bigpond.com ([58.175.155.56]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20091204103722.UKNW1310.nskntmtas03p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com>; Fri, 4 Dec 2009 10:37:22 +0000 Received: from [192.168.0.2] (really [58.175.155.56]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20091204103721.CRCM17290.nskntotgx01p.mx.bigpond.com@[192.168.0.2]>; Fri, 4 Dec 2009 10:37:21 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1-295483188 From: James Manger In-Reply-To: <4B188413.2070303@extendedsubset.com> Date: Fri, 4 Dec 2009 21:37:20 +1100 Message-Id: <58AAE640-FAE0-493A-A2EF-FCA0EE4E3816@manger.com.au> References: <200912040154.nB41sIt2029221@fs4113.wdf.sap.corp> <4B188413.2070303@extendedsubset.com> To: Marsh Ray X-Mailer: Apple Mail (2.1077) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4B18E662.0032,ss=1,fgs=0 Cc: "tls@ietf.org Working Group" Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 10:37:33 -0000 --Apple-Mail-1-295483188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Marsh, > In other words, an endpoint could > renegotiate an anonymous connection ten times to provide ten different > certificates, and the other party can securely treat all data sent = over > that connection as having been authenticated to all ten certificates! This point about all data being authenticated by all certs is a good = point to emphasis. Unfortunately, it does not mean typical applications wont get confused = (ie have vulnerabilities) when they hadn't explicitly anticipated that = 10 certs could be renegotiated. > I have a driver's license issued by Kansas and a passport issued by = the > US Dept of State, yet I do not assume two different identities. > Sometimes, I am even requested to provide both! Consider turning up to a Whitehouse check point, showing your = credentials to a guard, and "renegotiating" whenever you like by showing = another credential. A controller talking to the guard on the phone asks: [controller] What is the name on the credential? [guard] Marsh Ray [controller] Type of credential? [guard] passport now you show the guard your driver license [controller] Issuer of credential? [guard] Kansas The controller thinks he has authenticated Marsh Ray with a passport = issued by Kansas. If you happen to have a library card under a fake name and you showed = that first, the controller might think he has authenticated Bugs Bunny = with a Passport from the US Dept of State. Ouch! That might allow the = wrong person into a Whitehouse party ;-) In this analogy, the guard is a TLS library, the controller is an = application, your cards are certificates, and the protocol of showing = your cards is TLS (with the fix!). Is the error the controller's fault or the guards fault? The = application's or the TLS library's (or the protocol's for not providing = sufficient guidance)? This suggests another way for a TLS library to ensure it doesn't confuse = an application that doesn't explicitly stated it is prepared for = renegotiations. A library could tell the application only about one peer identity it = authenticates (probably the first it authenticates). For instance, Java's HttpsURLConnection.getServerCertificates() method = could return the same set of certificates for the life of the object = (the life of the TLS connection), and simply not tell the application = about any different certificates from renegotiations. The TLS library = could still renegotiate and switch to new sessions, but the application = would be blissfully unaware -- and still secure. Somehow this behaviour doesn't feel quite right, but I think it would be = ok. It might be easier to implement than comparing identities across = negotiations, and it would cope with those (somewhat unbelievable) niche = cases of renegotiating with a re-issued certificate etc. --=20 James Manger= --Apple-Mail-1-295483188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
In other = words, an endpoint could
renegotiate an anonymous connection ten = times to provide ten different
certificates, and the other party can = securely treat all data sent over
that connection as having been = authenticated to all ten = certificates!

This point = about all data being authenticated by all certs is a good point to = emphasis.
Unfortunately, it does not mean typical applications = wont get confused (ie have vulnerabilities) when they hadn't explicitly = anticipated that 10 certs could be = renegotiated.

I have a = driver's license issued by Kansas and a passport issued by the
US = Dept of State, yet I do not assume two different = identities.
Sometimes, I am even requested to provide = both!

Consider turning up to a = Whitehouse check point, showing your credentials to a guard, and = "renegotiating" whenever you like by showing another credential. A = controller talking to the guard on the phone = asks:
[controller] What is the name on the = credential?
[guard] Marsh Ray
[controller] Type of = credential?
[guard] passport
now you show the = guard your driver license
[controller] Issuer of = credential?
[guard] Kansas

The = controller thinks he has authenticated Marsh Ray with a passport issued = by Kansas.
If you happen to have a library card under a fake = name and you showed that first, the controller might think he has = authenticated Bugs Bunny with a Passport from the US Dept of State. = Ouch! That might allow the wrong person into a Whitehouse party = ;-)

In this analogy, the guard is a TLS = library, the controller is an application, your cards are certificates, = and the protocol of showing your cards is TLS (with the = fix!).

Is the error the controller's fault or = the guards fault? The application's or the TLS library's (or the = protocol's for not providing sufficient = guidance)?


This suggests another = way for a TLS library to ensure it doesn't confuse an application that = doesn't explicitly stated it is prepared for renegotiations.
A = library could tell the application only about one peer identity it = authenticates (probably the first it authenticates).
For = instance, Java's HttpsURLConnection.getServerCertificates() method could = return the same set of certificates for the life of the object (the life = of the TLS connection), and simply not tell the application about any = different certificates from renegotiations. The TLS library could still = renegotiate and switch to new sessions, but the application would be = blissfully unaware -- and still secure.

Somehow = this behaviour doesn't feel quite right, but I think it would be ok. It = might be easier to implement than comparing identities across = negotiations, and it would cope with those (somewhat unbelievable) niche = cases of renegotiating with a re-issued certificate = etc.

-- 
James = Manger
= --Apple-Mail-1-295483188-- From Pasi.Eronen@nokia.com Fri Dec 4 05: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 AC9543A688E for ; Fri, 4 Dec 2009 05:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 zM8Waq0-fJ7z for ; Fri, 4 Dec 2009 05:30:21 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7D4663A6826 for ; Fri, 4 Dec 2009 05:30:20 -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 nB4DTv0V010967; Fri, 4 Dec 2009 15:30:02 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 15:29:56 +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); Fri, 4 Dec 2009 15:29:51 +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, 4 Dec 2009 14:29:51 +0100 From: To: Date: Fri, 4 Dec 2009 14:29:50 +0100 Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpyb3kNprPvwWFQQHmegQWsADJVqgCdaLYw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3128928A@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> <2D9C122C-23B4-4284-93B2-FFADF33798C4@checkpoint.com> In-Reply-To: <2D9C122C-23B4-4284-93B2-FFADF33798C4@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 X-OriginalArrivalTime: 04 Dec 2009 13:29:51.0537 (UTC) FILETIME=[DBAD2210:01CA74E5] 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: Fri, 04 Dec 2009 13:30:22 -0000 Yoav Nir 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. >=20 > I think there should be some form of extension-less signaling from > client to server, at least for SSLv3 and TLS 1.0 on the initial > handshake.=20 The current draft has exactly this (as far as I can tell) -- so are you OK with that part (and agree that the remaining issue is sending-or-not-sending verify_data over-the-wire), or are you proposing changes to the signalling part, too?=20 (From your other email on the same day, I got the impression you were not happy with the signalling part either...)=20 Best regards, Pasi From Pasi.Eronen@nokia.com Fri Dec 4 05:30: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 910A23A6A14 for ; Fri, 4 Dec 2009 05:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 JURiKZG3Df7m for ; Fri, 4 Dec 2009 05:30:41 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7F6933A6A13 for ; Fri, 4 Dec 2009 05:30:41 -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 nB4DUMCM024337; Fri, 4 Dec 2009 15:30:28 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 15:30:26 +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, 4 Dec 2009 15:30: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; Fri, 4 Dec 2009 14:29:54 +0100 From: To: Date: Fri, 4 Dec 2009 14:29:53 +0100 Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acpyb3kNprPvwWFQQHmegQWsADJVqgCdSfGw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3128928B@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> <2D9C122C-23B4-4284-93B2-FFADF33798C4@checkpoint.com> In-Reply-To: <2D9C122C-23B4-4284-93B2-FFADF33798C4@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 X-OriginalArrivalTime: 04 Dec 2009 13:30:20.0614 (UTC) FILETIME=[ED01EE60:01CA74E5] 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: Fri, 04 Dec 2009 13:30:42 -0000 Yoav Nir 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. >=20 > I think there should be some form of extension-less signaling from > client to server, at least for SSLv3 and TLS 1.0 on the initial > handshake.=20 The current draft has exactly this (as far as I can tell) -- so are you OK with that part (and agree that the remaining issue is sending-or-not-sending verify_data over-the-wire), or are you proposing changes to the signalling part, too?=20 (From your other email on the same day, I got the impression you were not happy with the signalling part either...)=20 Best regards, Pasi From marsh@extendedsubset.com Fri Dec 4 05:42: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 7CC393A691E for ; Fri, 4 Dec 2009 05:42: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 JRuBJCFEMULK for ; Fri, 4 Dec 2009 05:42: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 6F4D73A68D1 for ; Fri, 4 Dec 2009 05:42:08 -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 1NGYQ2-000NGC-GK; Fri, 04 Dec 2009 13:41:59 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0ACF6603C; Fri, 4 Dec 2009 13:41: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+e2s3U2SK0X/BilcmZS4CS92fsJ1FQNTI= Message-ID: <4B1911A2.40701@extendedsubset.com> Date: Fri, 04 Dec 2009 07:41:54 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: James Manger References: <200912040154.nB41sIt2029221@fs4113.wdf.sap.corp> <4B188413.2070303@extendedsubset.com> <58AAE640-FAE0-493A-A2EF-FCA0EE4E3816@manger.com.au> In-Reply-To: <58AAE640-FAE0-493A-A2EF-FCA0EE4E3816@manger.com.au> 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 Working Group" Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 13:42:09 -0000 James Manger wrote: > Marsh, > >> In other words, an endpoint could >> renegotiate an anonymous connection ten times to provide ten different >> certificates, and the other party can securely treat all data sent over >> that connection as having been authenticated to all ten certificates! > > This point about all data being authenticated by all certs is a good > point to emphasis. > Unfortunately, it does not mean typical applications wont get confused > (ie have vulnerabilities) when they hadn't explicitly anticipated that > 10 certs could be renegotiated. Yep. >> I have a driver's license issued by Kansas and a passport issued by the >> US Dept of State, yet I do not assume two different identities. >> Sometimes, I am even requested to provide both! > > Consider turning up to a Whitehouse check point, showing your > credentials to a guard, and "renegotiating" whenever you like by showing > another credential. A controller talking to the guard on the phone asks: > [controller] What is the name on the credential? > [guard] Marsh Ray > [controller] Type of credential? > [guard] passport > /now you show the guard your driver license/ > [controller] Issuer of credential? > [guard] Kansas > > The controller thinks he has authenticated Marsh Ray with a passport > issued by Kansas. lol - good example > If you happen to have a library card under a fake name and you showed > that first, the controller might think he has authenticated Bugs Bunny > with a Passport from the US Dept of State. Ouch! That might allow the > wrong person into a Whitehouse party ;-) > > In this analogy, the guard is a TLS library, the controller is an > application, your cards are certificates, and the protocol of showing > your cards is TLS (with the fix!). In real applications, there's also the possibility you could end up authenticated as Kansas. > Is the error the controller's fault or the guards fault? The > application's or the TLS library's (or the protocol's for not providing > sufficient guidance)? Oh there's probably enough blame to go all around. > This suggests another way for a TLS library to ensure it doesn't confuse > an application that doesn't explicitly stated it is prepared for > renegotiations. I think it's becoming clear that very few application developers realized that TLS had this capacity for renegotiation, much less that their TLS library was doing it automatically. 'No renegotiation' is probably a good default. > A library could tell the application only about one peer identity it > authenticates (probably the first it authenticates). > For instance, Java's HttpsURLConnection.getServerCertificates() method > could return the same set of certificates for the life of the object > (the life of the TLS connection), and simply not tell the application > about any different certificates from renegotiations. The TLS library > could still renegotiate and switch to new sessions, but the application > would be blissfully unaware -- and still secure. > > Somehow this behaviour doesn't feel quite right, but I think it would be > ok. Does seem a bit busted. The application may be renegotiating for the explicit purpose of dropping credentials, such as when switching to a new identity. There's no solution short of disabling renegotiation by default, seeing what breaks, and helping app developers fix it securely. But that's a decision for each library vendor independently, not for the TLS wire protocol spec. > It might be easier to implement than comparing identities across > negotiations, and it would cope with those (somewhat unbelievable) niche > cases of renegotiating with a re-issued certificate etc. SSL/TLS has been around long enough, and has been popular enough, that it's pretty much guaranteed to have some of everything in operation. Any change to the semantics of the protocol or widely-used interfaces is going to break something. It's a question of how much you break, whether anything ends up less secure as a result, and whether the result ends up being easier or harder to understand. Solutions that involve adding new logic (such as keeping the old certificate and showing it to the application in place of the new) seem to have a lot of potential for breaking things in subtle and silent ways. - Marsh From mrex@sap.com Fri Dec 4 06:07: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 317013A6A19 for ; Fri, 4 Dec 2009 06:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Blp-HS+K98ps for ; Fri, 4 Dec 2009 06:07: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 11B9E3A6889 for ; Fri, 4 Dec 2009 06:07:23 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB4E774K005216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 15:07:07 +0100 (MET) From: Martin Rex Message-Id: <200912041407.nB4E76dQ011303@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Fri, 4 Dec 2009 15:07:06 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3128928A@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 4, 9 02:29:50 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] 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: Fri, 04 Dec 2009 14:07:25 -0000 Pasi.Eronen@nokia.com wrote: > > Yoav Nir 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. > > > > I think there should be some form of extension-less signaling from > > client to server, at least for SSLv3 and TLS 1.0 on the initial > > handshake. > > The current draft has exactly this (as far as I can tell) -- so > are you OK with that part (and agree that the remaining issue > is sending-or-not-sending verify_data over-the-wire), or are > you proposing changes to the signalling part, too? Mine does, TLS extension RI doesn't. Think about the following scenario: Updated TLS client establishes session with _old_ server. The old server requests renegotiation and were still early in the transition period, so the user really wants his client to allow that. What should the TLS client send on the renegotiation ClientHello to that old server? What if the client used an extension-less ClientHello for the initial handshake? what if that old server is actually extensions-intolerant? So: what should that client send on the renegotiation handshake with that server? Does the answer differ based on which kind of old server that is? The answer for my proposal is obvious, described in my document and fully interoperable with the entire installed base. The answer for TLS extension RI is not in that document, non-obvious and will either be insecure or break interop for some scenarios. -Martin From mike-list@pobox.com Fri Dec 4 08:06: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 091D83A680D for ; Fri, 4 Dec 2009 08:06:55 -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 LUr4orwrkdpF for ; Fri, 4 Dec 2009 08:06: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 6938B3A68BE for ; Fri, 4 Dec 2009 08:06: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 041FCA4035 for ; Fri, 4 Dec 2009 11:06: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=nDLcnhmM1IkF IWkPMIDbaAgZ+lc=; b=lWD6ts2NG2VziUHBrWQv2KnfK413bx6PdJmKYc6EM8xb IRh/LFTDc7y8Y0jAK/6JlpLOyjMsASekOidJBNSZocKxQauZ7OgLKfJkq+UIxzlc kW1mYhp3+XGoVLc58AGBW+fb0ULgnVowx0OR5p6299qfsHEJZHnLAep2BW8ofv0= 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=aCe1vN aEGGc/qIAyiDZ4OVrRfI0dFQUbvtxUUntAfbls3ucUKCmuHcVqE3cZNETUATcV8P 9ln7JsHeC0yPXCG7z6JhZflfqxNlr2KYAifQeFJNHWT9nC4PKa/OPM9JhQDv6C41 PXssVOK1JPxElntYna9R8UVlmQEqGiKTqUvDM= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0052AA4034 for ; Fri, 4 Dec 2009 11:06:41 -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 C5709A4033 for ; Fri, 4 Dec 2009 11:06:37 -0500 (EST) Message-ID: <4B1933F2.8060208@pobox.com> Date: Fri, 04 Dec 2009 08:08:18 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B18314E.3000002@pobox.com> <4B1873A3.7060900@jacaranda.org> <4B187DFF.2070708@pobox.com> <4B189B5D.5030907@extendedsubset.com> In-Reply-To: <4B189B5D.5030907@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 02FC1FC2-E0EF-11DE-B63B-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 16:06:55 -0000 Marsh, While I'm sure it was fun to write your amusing response to my message, your argument is fatally flawed because it is based on a premise that you yourself don't even believe. In the message I'm responding to, you state that the people responsible for implementing the RI extension: A) might not be fully aware of all the nuances of TLS and TLS extensions, such that they may assume incorrectly that there is an ordering to extensions B) might incorrectly conclude that the assumption in (A) is valid, based on observations of other implementations they are testing against, and not based on what the specs actually say C) might ship a patched client or server that requires the RI extension to be in a particular location in the list, causing considerable problems in the field due to their faulty assumption and limited testing But, when I used nearly exactly the same argument to justify the need for our fix to be FAIL-SAFE, you had a much different view of so-called maintenance programmers. My argument was that the people implementing the RI extension: A) might not be fully aware of all the nuances of TLS and TLS extensions, such that they may believe merely sending the old verify_data over the wire is what makes them safe B) might incorrectly conclude that the assumption in (A) is valid, based on their ability to interoperate with other implementations during initial handshakes and renegotiation handshakes, even though they never check the data C) might ship a patched client or server that appears to be patched, but yet is still completely vulnerable to MitM attacks since the old verify_data is not checked for accuracy Here is how you characterized "maintenance programmers" in a message on November 30: "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." I'm sorry but you can not choose when you believe what you said in this old message and when you believe what you said in yesterday's message. In order to believe both of these conflicting characterizations, they would have to be: A) smart enough to know that they need to check the verify_data sent in the RI extension B) not smart enough to realize that extensions are not ordered C) smart enough to create test cases where the verify_data is incorrect D) not smart enough to create test cases where the RI extension is not first in the list I think instead, you have made a pretty good argument for the need for our fix to be fail-safe! Mike Marsh Ray wrote: > Michael D'Errico wrote: >> If someone plans to make a device to detect the RI extension (possibly >> as part of a firewall or similar), then the closer it is to the front >> of the list, the less delay will be added to the processing of the >> connection, and the more connections can be handled per second. We >> definitely don't want our fix to slow down the establishment of all >> secure connections by any significant amount. > > We are talking about iterating bits of data that generally comes in over > a network, right? > > Let's say the IETF gets really creative and we end up with of 20 > extensions on every Client Hello. The order is well-randomized, so the > server has to "wade through" an average of 10 extensions to find the RI. > Some of these extensions are really, really big (several KB). So big > that for half of them the beginning of the next one hasn't even been > fetched into the data cache yet. > > So it's reasonable to assume that the cost will be predominated by five > cold access to slow DRAM at 200ns each. Let's see that comes to... 1 us! > Well a microsecond is nothing to sneeze at. > > During this microsecond many modern CPUs can be processing bits of other > connections (that do happen to be in the data cache), so some of that > might be hidden in the total throughput. Not to mention that presumably > there will be other reasons to "wade through" the extensions like if > somebody actually wants to process one for something useful. (For > comparison, my modern CPU takes about 18 ms to do an RSA in the > handshake, but I know dedicated hardware is much much faster). > > Well, we don't know how long the device takes to process a handshake > without extensions, so it's hard to say what impact randomized ordering > will have. > > We do know from experience that many devices end up being network-bound > rather that CPU- or memory-access-bound. It looks like there's a > two-byte length for all extensions, which strongly implies that the > maximum extension data is 64KB. Let's assume those five memory accesses > were over 16KB of data (data that somehow didn't make it into the cache). > > What speed of network is necessary to be only 10 times slower than us > wading through this morass of extensions? 16KB*8/1us/10 ... I get about > 13G bit/s. > > So my rough estimate is that an implementation using a conventional > memory architecture could saturate a full-duplex GigE link doing nothing > but exchanging hellos loaded-out with extensions and still have 10-100x > of headroom. > > This assumes of course that magic hardware makes all the other > calculations instantaneous. To the extent that assumption is false, the > overhead of wading through the extensions becomes rapidly even less > significant. > > Now what happens if 90% of implementors take your recommendation and put > the RI first in the list every time (for optimum performance of course)? > > A few things happen: > > 1. Some development group accidentally writes code that makes an > assumption that the ordering is consistent (possibly they aren't native > speakers of RFC 2119). > > 2. A Testing and Verification "QA" department tests their product's > interoperability with four different independent implementations. They > don't realize that all four took the recommendation on ordering, but > others that they didn't test with use some other ordering. > > 3. Two percent of the servers on the internet end up hanging the > connection in a slow failure mode when they get a client hello with > sub-optimally ordered extensions. > > 4. One of the top four major web browsers sends extensions in some > arbitrary data-dependent order. The RI extension ends up with about a > 33% chance of being first. It takes a minor research effort to figure > out why 1.33% of connections end up falling back to extensionless SSLv3. > > 5. The hello extension mechanism gets a permanent reputation as "not > ready to require the use of on the real internet". > > 6. Consequently, the SNI extension is unsuitable for deployment by > shared hosting providers, so every HTTPS site needs its own IP. The > world develops an acute shortage of routable IPv4 addresses when > Twitbook buys Verisign and convinces everyone that they need a > personalized certificate for their page. Everyone switches to IPv6 (ok > now it's getting a bit far-fetched). > > And last but not least: > > 6. Some big bloated client hello message somewhere gets processed 1 > microsecond faster. > > - Marsh > From mike-list@pobox.com Fri Dec 4 09: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 9A6043A6878 for ; Fri, 4 Dec 2009 09:04:45 -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 xfD2F2lCeNwG for ; Fri, 4 Dec 2009 09:04: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 142003A684A for ; Fri, 4 Dec 2009 09:04: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 16975A451B for ; Fri, 4 Dec 2009 12:04: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=hjc1iabPYEpy JOX5ROIZ4C8d54c=; b=l1ZcowgEnO6cTNOClak1jsvpx4UBXZLf7NDwE3tF4vVn DcxloIdYnjUGQHN3sydT9zCUYcPkeE/9B6jF4zoMO7hRueEy3ZHRliGJ8pOU89i/ nhGuqWjLDtlNzvCPVx8ZgTpOjkf4mkT7Gd50rUv36WtIpa5CdzEJ9X34BPr32v8= 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=d4EMFl 7Cf2c82tH4bdcu0kXGrN6rzdIxRvgnKNTAJmZXNnYGlugktz+JwGu4TQbiP1JtME 7h73yCuBI2/ZbxBSNGXToU3odsEs6BH3dE8vxNsgoZwbxqT1293gydJss8Z877sx 97whu/6ML7lLxO08rc/UVhxuFkEeFUpVK7rcc= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 14AD5A451A for ; Fri, 4 Dec 2009 12:04: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-sd.pobox.com (Postfix) with ESMTPSA id 586DAA4519 for ; Fri, 4 Dec 2009 12:04:34 -0500 (EST) Message-ID: <4B194186.6020205@pobox.com> Date: Fri, 04 Dec 2009 09:06:14 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B18314E.3000002@pobox.com> <4B1873A3.7060900@jacaranda.org> <4B187DFF.2070708@pobox.com> <4B189B5D.5030907@extendedsubset.com> <4B1933F2.8060208@pobox.com> In-Reply-To: <4B1933F2.8060208@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 191A902E-E0F7-11DE-80DF-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Last Call: 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, 04 Dec 2009 17:04:45 -0000 Clarification: The quote I used from Marsh was not arguing against a fail-safe approach, but the complexity of parsing the RI extension. Nevertheless, my conclusion is the same: you can not hold two conflicting views and pull out the one that supports your current argument. Mike Michael D'Errico wrote: > Marsh, > > While I'm sure it was fun to write your amusing response to my message, > your argument is fatally flawed because it is based on a premise that > you yourself don't even believe. In the message I'm responding to, you > state that the people responsible for implementing the RI extension: > > A) might not be fully aware of all the nuances of TLS and > TLS extensions, such that they may assume incorrectly > that there is an ordering to extensions > B) might incorrectly conclude that the assumption in (A) is > valid, based on observations of other implementations > they are testing against, and not based on what the specs > actually say > C) might ship a patched client or server that requires the > RI extension to be in a particular location in the list, > causing considerable problems in the field due to their > faulty assumption and limited testing > > But, when I used nearly exactly the same argument to justify the need > for our fix to be FAIL-SAFE, you had a much different view of so-called > maintenance programmers. My argument was that the people implementing > the RI extension: > > A) might not be fully aware of all the nuances of TLS and > TLS extensions, such that they may believe merely sending > the old verify_data over the wire is what makes them safe > B) might incorrectly conclude that the assumption in (A) is > valid, based on their ability to interoperate with other > implementations during initial handshakes and renegotiation > handshakes, even though they never check the data > C) might ship a patched client or server that appears to be > patched, but yet is still completely vulnerable to MitM > attacks since the old verify_data is not checked for accuracy > > Here is how you characterized "maintenance programmers" in a message > on November 30: > > "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." > > I'm sorry but you can not choose when you believe what you said in this > old message and when you believe what you said in yesterday's message. > > In order to believe both of these conflicting characterizations, they > would have to be: > > A) smart enough to know that they need to check the verify_data > sent in the RI extension > B) not smart enough to realize that extensions are not ordered > C) smart enough to create test cases where the verify_data is > incorrect > D) not smart enough to create test cases where the RI extension > is not first in the list > > I think instead, you have made a pretty good argument for the need for > our fix to be fail-safe! > > Mike > > > > Marsh Ray wrote: >> Michael D'Errico wrote: >>> If someone plans to make a device to detect the RI extension (possibly >>> as part of a firewall or similar), then the closer it is to the front >>> of the list, the less delay will be added to the processing of the >>> connection, and the more connections can be handled per second. We >>> definitely don't want our fix to slow down the establishment of all >>> secure connections by any significant amount. >> >> We are talking about iterating bits of data that generally comes in over >> a network, right? >> >> Let's say the IETF gets really creative and we end up with of 20 >> extensions on every Client Hello. The order is well-randomized, so the >> server has to "wade through" an average of 10 extensions to find the RI. >> Some of these extensions are really, really big (several KB). So big >> that for half of them the beginning of the next one hasn't even been >> fetched into the data cache yet. >> >> So it's reasonable to assume that the cost will be predominated by five >> cold access to slow DRAM at 200ns each. Let's see that comes to... 1 us! >> Well a microsecond is nothing to sneeze at. >> >> During this microsecond many modern CPUs can be processing bits of other >> connections (that do happen to be in the data cache), so some of that >> might be hidden in the total throughput. Not to mention that presumably >> there will be other reasons to "wade through" the extensions like if >> somebody actually wants to process one for something useful. (For >> comparison, my modern CPU takes about 18 ms to do an RSA in the >> handshake, but I know dedicated hardware is much much faster). >> >> Well, we don't know how long the device takes to process a handshake >> without extensions, so it's hard to say what impact randomized ordering >> will have. >> >> We do know from experience that many devices end up being network-bound >> rather that CPU- or memory-access-bound. It looks like there's a >> two-byte length for all extensions, which strongly implies that the >> maximum extension data is 64KB. Let's assume those five memory accesses >> were over 16KB of data (data that somehow didn't make it into the cache). >> >> What speed of network is necessary to be only 10 times slower than us >> wading through this morass of extensions? 16KB*8/1us/10 ... I get about >> 13G bit/s. >> >> So my rough estimate is that an implementation using a conventional >> memory architecture could saturate a full-duplex GigE link doing nothing >> but exchanging hellos loaded-out with extensions and still have 10-100x >> of headroom. >> >> This assumes of course that magic hardware makes all the other >> calculations instantaneous. To the extent that assumption is false, the >> overhead of wading through the extensions becomes rapidly even less >> significant. >> >> Now what happens if 90% of implementors take your recommendation and put >> the RI first in the list every time (for optimum performance of course)? >> >> A few things happen: >> >> 1. Some development group accidentally writes code that makes an >> assumption that the ordering is consistent (possibly they aren't native >> speakers of RFC 2119). >> >> 2. A Testing and Verification "QA" department tests their product's >> interoperability with four different independent implementations. They >> don't realize that all four took the recommendation on ordering, but >> others that they didn't test with use some other ordering. >> >> 3. Two percent of the servers on the internet end up hanging the >> connection in a slow failure mode when they get a client hello with >> sub-optimally ordered extensions. >> >> 4. One of the top four major web browsers sends extensions in some >> arbitrary data-dependent order. The RI extension ends up with about a >> 33% chance of being first. It takes a minor research effort to figure >> out why 1.33% of connections end up falling back to extensionless SSLv3. >> >> 5. The hello extension mechanism gets a permanent reputation as "not >> ready to require the use of on the real internet". >> >> 6. Consequently, the SNI extension is unsuitable for deployment by >> shared hosting providers, so every HTTPS site needs its own IP. The >> world develops an acute shortage of routable IPv4 addresses when >> Twitbook buys Verisign and convinces everyone that they need a >> personalized certificate for their page. Everyone switches to IPv6 (ok >> now it's getting a bit far-fetched). >> >> And last but not least: >> >> 6. Some big bloated client hello message somewhere gets processed 1 >> microsecond faster. >> >> - Marsh >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From dean@av8.com Fri Dec 4 09: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 0A1B63A6817 for ; Fri, 4 Dec 2009 09:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr3WWIoo2IfB for ; Fri, 4 Dec 2009 09:07:09 -0800 (PST) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id BB2933A684A for ; Fri, 4 Dec 2009 09:07:08 -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 nB4H6uJ2019174 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Dec 2009 12:06:56 -0500 Date: Fri, 4 Dec 2009 12:06:55 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Richard Stallman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf-honest@lists.iadl.org, tglassey@earthlink.net, 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 List-Id: "This is the mailing list 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, 04 Dec 2009 17:07:10 -0000 On Fri, 4 Dec 2009, Richard Stallman wrote: > Trademarks could affect a standard if the standard incorporates the > trademark in the text. > > I don't think so. You can write about a Ford car and call it that, > without infringing the trademark on Ford. If you are actually refering to a Ford, then yes. But if you _called_ your thing a "Ford", then no. A standard on "Open Systems" might have run afoul of Sun's trademark, had that term been successfully trademarked. [Sun actually wasn't successful, so I'm going to use this as a hypothetical example assuming they were successful.] A lot of things are known to be trademarked and refer to known products. But a lot aren't so obvious. Going back to the "Open Systems" example, if Sun hypothetically submits a standard naming something "Open Systems"; and we didn't notice the trademark; we approve the standard; later Sun comes around to the Standard users/implementers and says they are the only ones who can implement/use the standard using that name, and show the trademark documentation. Then it would seem that the IETF has endorsed Sun, and in anycase everyone else is screwed. We would want a declaration that they don't have any trademarks, copyrights, patents, or trade secrets in the document. You are quite correct that trade secrets aren't secret once they are put in a public document such as a standards draft. However, in each of the patent non-disclosure cases, the authors subsequently said they had secrets they were trying to keep. Well, if we make authors declare they have no trade secrets relating to the draft, we can more easily catch them in the lie. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494 From marsh@extendedsubset.com Fri Dec 4 09:19: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 EC1B93A682B for ; Fri, 4 Dec 2009 09:19:22 -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 LxyKakUqx-J3 for ; Fri, 4 Dec 2009 09:19: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 1DCF43A6A48 for ; Fri, 4 Dec 2009 09:19: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 1NGboA-000N1a-1r; Fri, 04 Dec 2009 17:19:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5EFCA603C; Fri, 4 Dec 2009 17:19: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: U2FsdGVkX19IATH3Pf57bmYQHNK5PskM5gaUpdGZCXE= Message-ID: <4B194482.6080204@extendedsubset.com> Date: Fri, 04 Dec 2009 11:18:58 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912041407.nB4E76dQ011303@fs4113.wdf.sap.corp> In-Reply-To: <200912041407.nB4E76dQ011303@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] 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, 04 Dec 2009 17:19:23 -0000 Martin Rex wrote: > > Think about the following scenario: > > Updated TLS client establishes session with _old_ server. The old server > requests renegotiation and were still early in the transition period, > so the user really wants his client to allow that. > > What should the TLS client send on the renegotiation ClientHello to > that old server? Awesome, thanks for bringing this up. It needs to be addressed in the draft. He SHOULD send the full RI extension with the most recent verify_data, even if he did not negotiate the use of RI in the initial handshake. If he sends just the MCSV, then the splicing-across-two-renegotiations attack is possible, even if the other target server is patched and in strict mode! If he sends nothing, the splicing-across-two-renegotiations attack is possible if the other target server is patched and in compatible mode. So the sentence applies equally to renegotiations: "If clients wish to ensure that such attacks are impossible, they MUST terminate the connection immediately upon failure to receive the extension without completing the handshake." - Marsh From frantz@pwpconsult.com Fri Dec 4 09:30: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 2CBA23A67EC for ; Fri, 4 Dec 2009 09:30:56 -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 IwzorRY0OtQz for ; Fri, 4 Dec 2009 09:30:55 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id E6D2D3A676A for ; Fri, 4 Dec 2009 09:30:54 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NGbzR-00035w-5Q; Fri, 04 Dec 2009 12:30:45 -0500 Date: Fri, 4 Dec 2009 09:31:25 -0800 From: Bill Frantz To: James Manger X-Priority: 3 In-Reply-To: <58AAE640-FAE0-493A-A2EF-FCA0EE4E3816@manger.com.au> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec798b7889ebd878abccbf82f58b6d314bd2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Cc: "tls@ietf.org Working Group" Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 17:30:56 -0000 james@manger.com.au (James Manger) on Friday, December 4, 2009 wrote: >This suggests another way for a TLS library to ensure it doesn't confuse a= n application that doesn't explicitly stated it is=20 >prepared for renegotiations. >A library could tell the application only about one peer identity it authe= nticates (probably the first it authenticates). >For instance, Java's HttpsURLConnection.getServerCertificates() method cou= ld return the same set of certificates for the life of=20 >the object (the life of the TLS connection), and simply not tell the appli= cation about any different certificates from=20 >renegotiations. The TLS library could still renegotiate and switch to new = sessions, but the application would be blissfully unaware=20 >-- and still secure. Yet another way would be to have the library return an array of structures, each member of which has the complete information from the client/server certificate chain.[1] This array would only grow as new certificates are received, leaving existing members constant. In Java, the array type would emphasize to the programmer that there might be more than one structure in the array. A C programmer would not have that protection, since in C it is easy to confuse an array reference with a reference to the first element. Cheers - Bill [1] The CA chain signing the certificate could be yet another array reference. ------------------------------------------------------------------------- Bill Frantz | When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 From mrex@sap.com Fri Dec 4 09:39: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 B8A8C3A68BE for ; Fri, 4 Dec 2009 09:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 hDq6+JDQ02Dg for ; Fri, 4 Dec 2009 09:39: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 B7F213A68A5 for ; Fri, 4 Dec 2009 09:39:08 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB4HcuPR027574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 18:38:56 +0100 (MET) From: Martin Rex Message-Id: <200912041738.nB4Hct87023458@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 4 Dec 2009 18:38:55 +0100 (MET) In-Reply-To: <4B194482.6080204@extendedsubset.com> from "Marsh Ray" at Dec 4, 9 11:18: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] 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: Fri, 04 Dec 2009 17:39:09 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > > Think about the following scenario: > > > > Updated TLS client establishes session with _old_ server. The old server > > requests renegotiation and were still early in the transition period, > > so the user really wants his client to allow that. > > > > What should the TLS client send on the renegotiation ClientHello to > > that old server? > > Awesome, thanks for bringing this up. It needs to be addressed in the draft. > > He SHOULD send the full RI extension with the most recent verify_data, > even if he did not negotiate the use of RI in the initial handshake. And this will break the backwards interop with the extensions-intolerant old server. The problem I have with this is: - it needs to be addressed in the TLS extenion RI draft, like a number of other special cases. - it breaks backwards interop - it's neither obvious nor documented in the current document I currently believe that this situation: - doesn't need to be special cased in my proposal - is fully covered by the existing description in my proposal - my proposal remains fully interoperable with old servers -Martin From ekr@networkresonance.com Fri Dec 4 09:41: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 743123A6811 for ; Fri, 4 Dec 2009 09:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[AWL=0.060, 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, 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 u4qG0WxR1K6u for ; Fri, 4 Dec 2009 09:40:59 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id C7ADD3A676A for ; Fri, 4 Dec 2009 09:40:59 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D79516C4CE9; Fri, 4 Dec 2009 09:42:17 -0800 (PST) Date: Fri, 04 Dec 2009 09:42:16 -0800 From: Eric Rescorla To: Marsh Ray In-Reply-To: <4B194482.6080204@extendedsubset.com> References: <200912041407.nB4E76dQ011303@fs4113.wdf.sap.corp> <4B194482.6080204@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: <20091204174217.D79516C4CE9@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: Fri, 04 Dec 2009 17:41:00 -0000 At Fri, 04 Dec 2009 11:18:58 -0600, Marsh Ray wrote: > > Martin Rex wrote: > > > > Think about the following scenario: > > > > Updated TLS client establishes session with _old_ server. The old server > > requests renegotiation and were still early in the transition period, > > so the user really wants his client to allow that. > > > > What should the TLS client send on the renegotiation ClientHello to > > that old server? > > Awesome, thanks for bringing this up. It needs to be addressed in the draft. > > He SHOULD send the full RI extension with the most recent verify_data, > even if he did not negotiate the use of RI in the initial handshake. I agree with this. Yes, this will cause interop failures with the small number of (insecure) extensions intolerant servers who want to renegotiate. I'm not convinced that that's unacceptable. > If he sends just the MCSV, then the splicing-across-two-renegotiations > attack is possible, even if the other target server is patched and in > strict mode! I actually don't think this is correct: Let's say you send MCSV... 1. If you're not being attacked then: - A handshake with an unupgraded server will succeed (it will ignore the MCSV) - A handshake with an upgraded server will fail [This should never happen because it should have responded with the extension initially.] 2. If you are being attacked (this would require the server's identity to change, of course): - If the server thinks this is a rehandshake it will reject the handshake right away. - If the server thinks this is an initial handshake it will accept the ClientHello but return an empty RI in ServerHello which will then be rejected by the client because the client is expecting to see the previous verify_data. What am I missing? -Ekr From mrex@sap.com Fri Dec 4 09:55: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 D3F6A3A6A3E for ; Fri, 4 Dec 2009 09:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 LI555oYUxi-D for ; Fri, 4 Dec 2009 09:55: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 C6DE93A672F for ; Fri, 4 Dec 2009 09:55:29 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB4HtIwY011254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 18:55:18 +0100 (MET) From: Martin Rex Message-Id: <200912041755.nB4HtH6r024368@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 4 Dec 2009 18:55:17 +0100 (MET) In-Reply-To: <20091204174217.D79516C4CE9@kilo.networkresonance.com> from "Eric Rescorla" at Dec 4, 9 09:42:16 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: Fri, 04 Dec 2009 17:55:30 -0000 Eric Rescorla wrote: > > At Fri, 04 Dec 2009 11:18:58 -0600, > Marsh Ray wrote: > > > > Martin Rex wrote: > > > > > > Think about the following scenario: > > > > > > Updated TLS client establishes session with _old_ server. The old server > > > requests renegotiation and were still early in the transition period, > > > so the user really wants his client to allow that. > > > > > > What should the TLS client send on the renegotiation ClientHello to > > > that old server? > > > > Awesome, thanks for bringing this up. It needs to be addressed in the draft. > > > > He SHOULD send the full RI extension with the most recent verify_data, > > even if he did not negotiate the use of RI in the initial handshake. > > I agree with this. > > Yes, this will cause interop failures with the small number of > (insecure) extensions intolerant servers who want to renegotiate. > I'm not convinced that that's unacceptable. My proposal doesn't have that shortcoming, besides being *MUCH* easier to implement and failSAFE. > > I actually don't think this is correct: > > Let's say you send MCSV... Which is less drastic to interop. > > 1. If you're not being attacked then: > - A handshake with an unupgraded server will succeed (it will > ignore the MCSV) agree. > > 2. If you are being attacked (this would require the server's identity > to change, of course): It is an entirely flawed assumption that the identity of the server will change! There are attacks where it doesn't, and they're much more plausible than the accidental collision of non-predictable verify_data which you considered so scary (before I patched that). > > - If the server thinks this is a rehandshake it will reject the > handshake right away. agree. > - If the server thinks this is an initial handshake it will accept > the ClientHello but return an empty RI in ServerHello which will > then be rejected by the client because the client is expecting > to see the previous verify_data. So you start to rely entirely on the client do check for a special case that you haven't even documented. Scary. It's much safer when both peers can determine in a failSAFE fashion that an MitM attack is performed. As in my proposal. -Martin From ekr@networkresonance.com Fri Dec 4 10:02: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 073F83A672F for ; Fri, 4 Dec 2009 10:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[AWL=0.050, 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, 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 Gak1+ZOWJqIr for ; Fri, 4 Dec 2009 10:02:37 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 588573A672E for ; Fri, 4 Dec 2009 10:02:37 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E097A6C4CEA; Fri, 4 Dec 2009 10:03:55 -0800 (PST) Date: Fri, 04 Dec 2009 10:03:55 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200912041755.nB4HtH6r024368@fs4113.wdf.sap.corp> References: <20091204174217.D79516C4CE9@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: <20091204180355.E097A6C4CEA@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: Fri, 04 Dec 2009 18:02:38 -0000 At Fri, 4 Dec 2009 18:55:17 +0100 (MET), Martin Rex wrote: > > 2. If you are being attacked (this would require the server's identity > > to change, of course): > > It is an entirely flawed assumption that the identity of the server will > change! There are attacks where it doesn't, and they're much more > plausible than the accidental collision of non-predictable verify_data > which you considered so scary (before I patched that). Well, this was just a note. However, how do you think the situation you are describing happens in an attack case without the server identity changing? > > - If the server thinks this is an initial handshake it will accept > > the ClientHello but return an empty RI in ServerHello which will > > then be rejected by the client because the client is expecting > > to see the previous verify_data. > > So you start to rely entirely on the client do check for a special > case that you haven't even documented. As I said, I think the correct behavior is to send RI. I was merely observing that even if you sent MCSV the handshake would still fail, as expected. -Ekr From marsh@extendedsubset.com Fri Dec 4 10:23: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 E25723A67FA for ; Fri, 4 Dec 2009 10:23:19 -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 g5dtRFOnaIk7 for ; Fri, 4 Dec 2009 10:23: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 9EBBF3A677D for ; Fri, 4 Dec 2009 10:23: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 1NGco9-000Mnj-C8; Fri, 04 Dec 2009 18:23:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2F875603C; Fri, 4 Dec 2009 18:23: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: U2FsdGVkX1//0vCHY6HEomuGfy1D7brX1pFuiEkNW/c= Message-ID: <4B195389.8060908@extendedsubset.com> Date: Fri, 04 Dec 2009 12:23:05 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <4B181209.5090507@extendedsubset.com> <200912032023.nB3KNIS2008868@fs4113.wdf.sap.corp> <4B18314E.3000002@pobox.com> <4B1873A3.7060900@jacaranda.org> <4B187DFF.2070708@pobox.com> <4B189B5D.5030907@extendedsubset.com> <4B1933F2.8060208@pobox.com> In-Reply-To: <4B1933F2.8060208@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] Last Call: 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, 04 Dec 2009 18:23:20 -0000 Michael D'Errico wrote: > Marsh, > > While I'm sure it was fun to write your amusing response to my > message, your argument is fatally flawed because it is based on a > premise that you yourself don't even believe. I'm glad you liked it. It wasn't meant to be a rigorous argument, just a probable scenario based on past experiences. However, I think I can adequately address the apparent inconsistencies. > In the message I'm responding to, you state that the people > responsible for implementing the RI extension: > > A) might not be fully aware of all the nuances of TLS and TLS > extensions, such that they may assume incorrectly that there is an > ordering to extensions B) might incorrectly conclude that the > assumption in (A) is valid, based on observations of other > implementations they are testing against, and not based on what the > specs actually say Or they might just be a bit careless, or otherwise careful but having a bad day. > C) might ship a patched client or server that requires the RI > extension to be in a particular location in the list, causing > considerable problems in the field due to their faulty assumption and > limited testing Yes, that can easily happen. > But, when I used nearly exactly the same argument to justify the need > for our fix to be FAIL-SAFE, you had a much different view of > so-called maintenance programmers. My argument was that the people > implementing the RI extension: > > A) might not be fully aware of all the nuances of TLS and TLS > extensions, such that they may believe merely sending the old > verify_data over the wire is what makes them safe Yes, that could happen if they weren't implementing the spec carefully. > B) might incorrectly conclude that the assumption in (A) is valid, > based on their ability to interoperate with other implementations > during initial handshakes and renegotiation handshakes, even though > they never check the data Yes, that could happen if they weren't implementing the spec carefully. > C) might ship a patched client or server that appears to be patched, > but yet is still completely vulnerable to MitM attacks since the old > verify_data is not checked for accuracy Yes, that could happen if they weren't implementing the spec carefully _and_ their testing process did not include any simulated attack (which we should still make a tool for). > Here is how you characterized "maintenance programmers" in a message > on November 30: > > "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." I agree with that, too, for conscientious implementors. > I'm sorry but you can not choose when you believe what you said in > this old message and when you believe what you said in yesterday's > message. Yesterday, we were talking about a failure mode where an implementation ends up still having the insecure behavior it has today, even after patching. That can be detected externally and remedied with another patch. This conversation is about the possibility of a small minority of servers poisoning the well for us all. In my experience, a really good programmer might get a project of this scope right the first time maybe 90% of the time. Pair that with a good test team and test plan and the success rate goes upwards of 99%. This will be true for all of the first-rate implementations, which are the ones that matter. They will be interop testing with each other, even if they do it secretly. They will probably all follow your recommended extension ordering, not so much for performance but out of conformity. On the other hand, probably not all of TLS implementors are consistently perfect. There is enough variation out there that we should plan for the scenario where somebody ends up shipping something imperfect. This is probably a rush job for some of them, some of them may be digging up old codebases and have lost the experience with it, and there will probably be a plain old mistake made somewhere. My guess is that the success rate for implementors writing new order-independent RI code when no implementations vary the order will be comparable to the success rate we saw for ignoring extra data on client hellos for SSLv3 and TLS 1.0 when no implementations actually were sending any. But many implementations already have decent support for extensions, and they might be in more of a security-careful state of mind, so maybe it will be better. I think the figure I proposed was 2%, could be much more or much less, who can predict? I'm sure it won't be zero however, and it might not take much to have a similar effect as the extra client hello data bugs have had on the uptake of extensions in general. > In order to believe both of these conflicting characterizations, they > would have to be: > > A) smart enough to know that they need to check the verify_data sent > in the RI extension > B) not smart enough to realize that extensions are not ordered Well, smart enough to know which specs to read and to read them. > C) smart enough to create test cases where the verify_data is > incorrect Hopefully there will be tool for this. > D) not smart enough to create test cases where the RI extension is > not first in the list Or they're under schedule pressure and don't have "extra" time to spend implementing a test client and server which sends them in variable orders. Coming up with new test cases for theoretical possibilities (e.g., none of the major implementations you interop with do it) is always the first thing to go out the window. The thoroughness of the test procedures is usually not decided by the maintenance programmer, but by company management and resources. > I think instead, you have made a pretty good argument for the need > for our fix to be fail-safe! Yes, the proposals involving the PRF input modifications are probably superior in that way. On balance, I feel the RI is adequate in design and can be deployed significantly faster. - Marsh From mrex@sap.com Fri Dec 4 10:51: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 14A0428C0F4 for ; Fri, 4 Dec 2009 10:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 eoHJgDeYDu6k for ; Fri, 4 Dec 2009 10:51: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 DE58428C105 for ; Fri, 4 Dec 2009 10:51:32 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB4IpKAt023678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 19:51:20 +0100 (MET) From: Martin Rex Message-Id: <200912041851.nB4IpJoG001567@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 4 Dec 2009 19:51:19 +0100 (MET) In-Reply-To: <20091204180355.E097A6C4CEA@kilo.networkresonance.com> from "Eric Rescorla" at Dec 4, 9 10:03:55 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: Fri, 04 Dec 2009 18:51:34 -0000 Eric Rescorla wrote: > > At Fri, 4 Dec 2009 18:55:17 +0100 (MET), > Martin Rex wrote: > > > 2. If you are being attacked (this would require the server's identity > > > to change, of course): > > > > It is an entirely flawed assumption that the identity of the server will > > change! There are attacks where it doesn't, and they're much more > > plausible than the accidental collision of non-predictable verify_data > > which you considered so scary (before I patched that). > > Well, this was just a note. However, how do you think the situation > you are describing happens in an attack case without the server > identity changing? The obvious one is this: http://www.ietf.org/mail-archive/web/tls/current/msg05127.html but as you can see from the other discussion threads, there may be a number of additional options based on some people's and some application's flawed assumptions about "same identity". But coming back to the original problem: The TLS WG has been asked to provide a secure renegotiation. I don't think TLS WG should ship an solution where we need a list of special cases, and where some of that actually involve mitigation strategies that the application has to implement, like a check that the identity of the remote peer doesn't change. > > > > - If the server thinks this is an initial handshake it will accept > > > the ClientHello but return an empty RI in ServerHello which will > > > then be rejected by the client because the client is expecting > > > to see the previous verify_data. > > > > So you start to rely entirely on the client do check for a special > > case that you haven't even documented. > > As I said, I think the correct behavior is to send RI. I was merely > observing that even if you sent MCSV the handshake would still > fail, as expected. I'm just looking at openssl-0.9.8-stable-SNAP-20091203. It doesn't seem to contain MCSV yet. The amount of code there to deal with the TLS extension RI is quite impressive. There is a whole seperate source file "t1_reneg.c" to deal with the contents of the TLS extension alone and contains 11 situations with comparisons where the handshake is aborted. There's more code in t1_lib.c to do the parsing of the extensions list to actually find that extension. That parser is far from trivial, and only implementations that already have it don't need to add that code. A quick glance suggests that you can append up to 3 arbitrary octets to the end of the TLS extensions list and OpenSSL will entirely ignore them. -Martin From ekr@networkresonance.com Fri Dec 4 10:59: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 B60A63A67D8 for ; Fri, 4 Dec 2009 10:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.938 X-Spam-Level: X-Spam-Status: No, score=0.938 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, 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 6ezKnIsb5DD6 for ; Fri, 4 Dec 2009 10:59:01 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 1EAC83A63EB for ; Fri, 4 Dec 2009 10:59:01 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 96A826C4D07; Fri, 4 Dec 2009 11:00:19 -0800 (PST) Date: Fri, 04 Dec 2009 11:00:18 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200912041851.nB4IpJoG001567@fs4113.wdf.sap.corp> References: <20091204180355.E097A6C4CEA@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: <20091204190019.96A826C4D07@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: Fri, 04 Dec 2009 18:59:01 -0000 At Fri, 4 Dec 2009 19:51:19 +0100 (MET), Martin Rex wrote: > Eric Rescorla wrote: > > Well, this was just a note. However, how do you think the situation > > you are describing happens in an attack case without the server > > identity changing? > > The obvious one is this: > http://www.ietf.org/mail-archive/web/tls/current/msg05127.html > > but as you can see from the other discussion threads, there may be > a number of additional options based on some people's and some > application's flawed assumptions about "same identity". > > But coming back to the original problem: > The TLS WG has been asked to provide a secure renegotiation. > > I don't think TLS WG should ship an solution where we need a list > of special cases, and where some of that actually involve mitigation > strategies that the application has to implement, like a check > that the identity of the remote peer doesn't change. As I said, this was just a note, not a requirement for RI to be secure in this case. Best, -Ekr From aerowolf@gmail.com Fri Dec 4 11:16: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 08FA53A685B for ; Fri, 4 Dec 2009 11:16:12 -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 Bx1YGkdxlGVx for ; Fri, 4 Dec 2009 11:16:11 -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 1294C3A63EB for ; Fri, 4 Dec 2009 11:16:11 -0800 (PST) Received: by pwi5 with SMTP id 5so1641915pwi.29 for ; Fri, 04 Dec 2009 11:16:00 -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=3ThMPSAAkV6qjJdX4q6wvnl7/ZsYDlgQLXoTJ/o5atQ=; b=VAsHqxUFXmNaO9he2gg+GslTXoMPiB8sP1aZJ4TuU8xPJAw+wn8TJ+RnWy2GWwePbk Bux648FXM+s0q4JmO+/kogky5iD3VBaIjhzdUWNYk71NtZnFmBvTJxqh5P/FP20hkBhQ drMXaqngkEuKZhGeX8hlq+r7vg9/tEsAZ70W8= 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=OvStU+8mmeCvj5t89/JWglfRpmKCxFTxD9BTVJGnM6W6oiZdp+YwDilHh4H2sr9/3n F32YCxfHuM4jO43U3YRi0rwWZMFePB7QOrUhI2WN52zb3y1kK72E16Y2oRxTyIWbmci7 iatq88cCn3KVf2m+//Gly2loNDBpenYO4PJ2Y= MIME-Version: 1.0 Received: by 10.143.24.42 with SMTP id b42mr457977wfj.41.1259954159866; Fri, 04 Dec 2009 11:15:59 -0800 (PST) In-Reply-To: <4B152A4C.9070702@cs.tcd.ie> References: <4B152A4C.9070702@cs.tcd.ie> Date: Fri, 4 Dec 2009 11:15:59 -0800 Message-ID: <6b9359640912041115t143fc568pb19048164a0b6ab6@mail.gmail.com> From: Kyle Hamilton To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, James Manger Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 19:16:12 -0000 PKIX -- as a subset of X.509 -- states that the Subject and Issuer together describe the identity. Specifically, the Subject contains the (unique) moniker for the entity which the certificate has been issued to. The Issuer describes which trust anchor to use to verify the signature. (Trust anchor management is horrible, and there's been no discussion of any UI to state that, for example, the "Snake Oil RSA Root" and "Snake Oil EC Root" are really the same Authority, simply with a different TA.) I believe that this specific issue (identity) is out of scope of TLS, and is within the scope of PKIX. Specifically, they've already defined a way to compare identities with certificates, and it certainly isn't with a bitwise comparison of an expired certificate! (Hint: the Subject contains several Directory Components, and each of those should be compared, if you want to verify that the identity hasn't changed.) In the alternative, I believe that the bit-wise comparison is worse than useless, and I believe that the "MAY" should be changed to a very strong "SHOULD". -Kyle H On Tue, Dec 1, 2009 at 6:38 AM, Stephen Farrell wrote: > > > James Manger wrote: >> I strongly support the consistent identity check in the Security Conside= rations section of draft-ietf-tls-renegotiation-01. > > Fair enough. > >> There may be some niche uses of TLS for which changing an identity durin= g renegotiation makes sense. That is adequately supported by the last parag= raph in the Security Considerations: "A TLS library MAY provide a means for= the application to allow identity and/or server_name changes across renego= tiations...". However, for 99.9...% of TLS uses an identity changing during= renegotiation will be totally unexpected by the higher-layer application a= nd can only cause problems. > > I'd buy that. > >> A few people have argued that the consistent identity check is a separat= e issue that should not be addressed now. I don't think that is a fair char= acterisation. > > I'm not sure what you mean by "characterisation." > > My point was simply that this *is* a different issue from the > renegotiation bug, that we're fixing that bug in "emergency" > mode and that we therefore shouldn't change *anything* else > whilst in that mode. > > To give one example - rfc 2712 says how to use kerberos with > TLS. (I've no idea if that's really in use.) The text in -01 > doesn't say how to handle that, but does have a MUST on > no-change. That could break something. I don't want to hold > the bug fix while we figure that out. > > I just thinks its safer to do this later with some other draft > that UPDATEs 5246. > > Stephen. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mrex@sap.com Fri Dec 4 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 51C703A67D8 for ; Fri, 4 Dec 2009 11:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 ZXii-HSn9grg for ; Fri, 4 Dec 2009 11: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 424E93A63EB for ; Fri, 4 Dec 2009 11:21:20 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB4JL9ff023972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 20:21:09 +0100 (MET) From: Martin Rex Message-Id: <200912041921.nB4JL8VW003302@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 4 Dec 2009 20:21:08 +0100 (MET) In-Reply-To: <20091204190019.96A826C4D07@kilo.networkresonance.com> from "Eric Rescorla" at Dec 4, 9 11:00:18 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: Fri, 04 Dec 2009 19:21:21 -0000 Eric Rescorla wrote: > > At Fri, 4 Dec 2009 19:51:19 +0100 (MET), > Martin Rex wrote: > > Eric Rescorla wrote: > > > Well, this was just a note. However, how do you think the situation > > > you are describing happens in an attack case without the server > > > identity changing? > > > > The obvious one is this: > > http://www.ietf.org/mail-archive/web/tls/current/msg05127.html > > > > but as you can see from the other discussion threads, there may be > > a number of additional options based on some people's and some > > application's flawed assumptions about "same identity". > > > > But coming back to the original problem: > > The TLS WG has been asked to provide a secure renegotiation. > > > > I don't think TLS WG should ship an solution where we need a list > > of special cases, and where some of that actually involve mitigation > > strategies that the application has to implement, like a check > > that the identity of the remote peer doesn't change. > > As I said, this was just a note, not a requirement for RI to > be secure in this case. Excuse me while I panic. You mean that you do not care the slightest if you're shipping a defective renegotiation protection that will allow an intruder or disgruntled admin in posession of the server credentials to inject data and splice TLS sessions in a fashion that will look like perfectly valid requests from the unsuspecting client/customer to all of the audit systems in the backend? Well, I do care. I do _not_ want the IETF to provide to malfeasants the perfect digital crow bar that doesn't leave any traces. -Martin From ekr@networkresonance.com Fri Dec 4 11:34: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 E04F63A67B0 for ; Fri, 4 Dec 2009 11:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.932 X-Spam-Level: X-Spam-Status: No, score=0.932 tagged_above=-999 required=5 tests=[AWL=0.037, 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, 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 KL8AHrXZm1AO for ; Fri, 4 Dec 2009 11:34:26 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 24A8C3A63EB for ; Fri, 4 Dec 2009 11:34:26 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id A00A96C4D17; Fri, 4 Dec 2009 11:35:44 -0800 (PST) Date: Fri, 04 Dec 2009 11:35:44 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200912041921.nB4JL8VW003302@fs4113.wdf.sap.corp> References: <20091204190019.96A826C4D07@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: <20091204193544.A00A96C4D17@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: Fri, 04 Dec 2009 19:34:27 -0000 At Fri, 4 Dec 2009 20:21:08 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > At Fri, 4 Dec 2009 19:51:19 +0100 (MET), > > Martin Rex wrote: > > > Eric Rescorla wrote: > > > > Well, this was just a note. However, how do you think the situation > > > > you are describing happens in an attack case without the server > > > > identity changing? > > > > > > The obvious one is this: > > > http://www.ietf.org/mail-archive/web/tls/current/msg05127.html > > > > > > but as you can see from the other discussion threads, there may be > > > a number of additional options based on some people's and some > > > application's flawed assumptions about "same identity". > > > > > > But coming back to the original problem: > > > The TLS WG has been asked to provide a secure renegotiation. > > > > > > I don't think TLS WG should ship an solution where we need a list > > > of special cases, and where some of that actually involve mitigation > > > strategies that the application has to implement, like a check > > > that the identity of the remote peer doesn't change. > > > > As I said, this was just a note, not a requirement for RI to > > be secure in this case. > > Excuse me while I panic. > > > You mean that you do not care the slightest if you're shipping > a defective renegotiation protection that will allow an intruder > or disgruntled admin in posession of the server credentials > to inject data and splice TLS sessions in a fashion that > will look like perfectly valid requests from the unsuspecting > client/customer to all of the audit systems in the backend? > > > Well, I do care. > > I do _not_ want the IETF to provide to malfeasants the perfect > digital crow bar that doesn't leave any traces. Oh, I'm terribly sorry, that must be about my worst writing ever. What I meant to say was rather: (a) I believe that RI is secure in the case you suggest. (b) I do not believe that checking for an identity change is required in order for (a) to be true. (c) I was merely noting that I believed identity would change. Sorry for the confusion. Best, -Ekr From aerowolf@gmail.com Fri Dec 4 11: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 CC0D43A6A1F for ; Fri, 4 Dec 2009 11:34:29 -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 9-lVnm+LKiAG for ; Fri, 4 Dec 2009 11:34:29 -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 EA4C73A63EB for ; Fri, 4 Dec 2009 11:34:28 -0800 (PST) Received: by pwi5 with SMTP id 5so1652763pwi.29 for ; Fri, 04 Dec 2009 11:34: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=0o4mIGOzn6PTHbIdnWxaLUkZqS5+p0sA8md9RobZS/0=; b=esge0/bTP0YxzCFczIwgyNvXoqnKgvhe6RWVUouwMHFrWQx7Wr7zoYz6xJHfOKbM/8 uPRmzc/lul3/h4Y7/QGSFE9hcpmBRr81btiO+Hi2BEUALhcmHhXgvSJhU0JQHx4/Ad97 ydiCNB8elR6nVM0He0hQvPe1/KpGiF1pAVJhg= 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=gyFdKzoto19BVdJMC7N8xbHOhEKUafnwajyBCfSJj1CeKHEGECcnO0maTwXDv9NfEx qZxYro5MS92XZAnxdIEIig6ko81x9I/ddQ9hy4/XRmTqKLlQGmDMpQ/nkfr+blYEion7 zS9FhnlVv/8QrdyekhBI3qd6H8ClSyPr6xWmc= MIME-Version: 1.0 Received: by 10.142.1.37 with SMTP id 37mr409574wfa.287.1259955257707; Fri, 04 Dec 2009 11:34:17 -0800 (PST) In-Reply-To: <4B185802.6070306@jacaranda.org> References: <4B17C2F9.9010802@extendedsubset.com> <4B18096E.20805@extendedsubset.com> <4B185802.6070306@jacaranda.org> Date: Fri, 4 Dec 2009 11:34:17 -0800 Message-ID: <6b9359640912041134x9be9271gc3cb521e00eb5e65@mail.gmail.com> From: Kyle Hamilton To: David-Sarah Hopwood Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] matching identity, by default X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 19:34:29 -0000 Isn't "SHOULD" something like "There are some really good reasons for us to recommend this, but we understand that there might be some really good reasons to ignore it"? I believe that "SHOULD" is the correct term for guidance to a programmer as far as his software interfacing with the protocol. "MUST" is the correct term for guidance to a programmer as far as the protocol interfacing with the network, as far as bits-on-the-wire goes. I think Marsh's wording is about the best that can be applied. I'd probably end up with something like "Sometimes processing this application data within handshake is desired, but generally a TLS implementation SHOULD discard any buffered plaintext before the renegotiation's Finished messages UNLESS the renegotiation has the same identity (as defined in [PKIX]). TLS implementations SHOULD expose the details of identity associated with each byte of application data, though the details of such an API are beyond the scope of this document." -Kyle H On Thu, Dec 3, 2009 at 4:29 PM, David-Sarah Hopwood wrote: > Marsh Ray wrote: >> * The TLS protocol allows application data to be interleaved within >> rengotiation handshake messages. Sometimes this is desired, but may >> require extra care. The application-supplied callback and TLS library >> normally SHOULD discard any buffered plaintext at the point of >> renegotiation. > > I appreciate the problem that this recommendation is trying to solve, > but as stated here it may do more harm than good. Discarding any plaintex= t > may cause the application protocol states at the client and server to > lose synchronization, creating a vulnerability, or at least incorrect > behaviour. > > -- > David-Sarah Hopwood =C2=A0=E2=9A=A5 =C2=A0http://davidsarah.livejournal.c= om > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From marsh@extendedsubset.com Fri Dec 4 12:19: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 647F43A6939 for ; Fri, 4 Dec 2009 12:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSu99wEXJnn3 for ; Fri, 4 Dec 2009 12:19:06 -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 45B6C3A6A64 for ; Fri, 4 Dec 2009 12:18: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 1NGebm-0009eu-41; Fri, 04 Dec 2009 20:18:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A8226603C; Fri, 4 Dec 2009 20:18: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/AO+OFwNYHSeNLAifVxz/5ghUPGYLYK4Q= Message-ID: <4B196E92.4010704@extendedsubset.com> Date: Fri, 04 Dec 2009 14:18:26 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: <20091204174217.D79516C4CE9@kilo.networkresonance.com> <20091204180355.E097A6C4CEA@kilo.networkresonance.com> In-Reply-To: <20091204180355.E097A6C4CEA@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: [TLS] draft-renego "even after previous handshakes ....did not negotiate the use of 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: Fri, 04 Dec 2009 20:19:07 -0000 Eric Rescorla wrote: > >>> - If the server thinks this is an initial handshake it will accept >>> the ClientHello but return an empty RI in ServerHello which will >>> then be rejected by the client because the client is expecting >>> to see the previous verify_data. >> So you start to rely entirely on the client do check for a special >> case that you haven't even documented. > > As I said, I think the correct behavior is to send RI. I was merely > observing that even if you sent MCSV the handshake would still > fail, as expected. To summarize, I think a valid point here is that a client implementation that didn't negotiate the use of RI on the initial handshake might not realize the need send the appropriate RI on every renegotiation, too. Even more possible is he might not consider the need to be looking for RI responses from the "server" and checking them against his expectations whenever they arrive. Here's some wording (use it if it helps): > 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. If the contents > are incorrect, then it MUST generate a fatal "handshake_failure" > alert and terminate the connection. This allows two implementations > both of which support the extension to safely renegotiate without > fear of the above attack. This requirement to validate any received RI extension still applies even after previous handshakes on the same the connection or session did not negotiate the use of RI. Every handshake must be treated independently in this respect because the attacker may attempt to make an initial handshake appear as a renegotiation handshake or vice-versa. > 5. Requirements for Sending and Receiving > > TLS clients which support this draft MUST generate either the > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > cipher suite with every ClientHello. > > TLS servers which support this draft MUST generate the > "renegotiation_info" extension in the ServerHello in response to any > client which offers either "renegotiation_info" or Client Hello > TLS_RENEGO_PROTECTION_REQUEST in the ClientHello. Note that these requirements still apply even after previous handshakes of the same the connection or session did not negotiate the use of RI. Every handshake is to be treated independently in this respect. - Marsh From mickgray@au1.ibm.com Fri Dec 4 13: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 636373A6833 for ; Fri, 4 Dec 2009 13:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 67PgVOPEKXVV for ; Fri, 4 Dec 2009 13:36:26 -0800 (PST) Received: from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141]) by core3.amsl.com (Postfix) with ESMTP id 129FB3A67F3 for ; Fri, 4 Dec 2009 13:36:25 -0800 (PST) Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp08.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB58aFLO022775 for ; Sat, 5 Dec 2009 19:36:15 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB4LaFCU1552560 for ; Sat, 5 Dec 2009 08:36:15 +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 nB4LaFDQ010125 for ; Sat, 5 Dec 2009 08:36:15 +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 nB4LaEjc010113 for ; Sat, 5 Dec 2009 08:36:14 +1100 In-Reply-To: <4B194186.6020205@pobox.com> To: tls@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Sat, 5 Dec 2009 07:35:56 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 05/12/2009 08:43:10 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation - deployment in legacy environments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2009 21:36:27 -0000 DQoNCldoZW4gY29uc2lkZXJpbmcgdGhlIGltcGFjdCBvZiBhcHBseWluZyB0aGlzIGZpeCBpbiBj ZXJ0YWluIHByb2R1Y3Rpb24NCmVudmlyb25tZW50cyBJIGhhdmUgaWRlbnRpZmllZCB0aGUgZm9s bG93aW5nIGlzc3VlczoNCg0KICAgICAgVGhlcmUgaXMgYSBwb3NzaWJseSBvZiBsZWdhY3kgc3lz dGVtcyBjb250YWluaW5nIFNTTCBpbXBsZW1lbnRhdGlvbnMNCiAgICAgIHRoYXQgYXJlIFNTTHYz IG9ubHkgYW5kIGNhbiBub3QgbmVnb3RpYXRlIFRMUyBpLmUuIHRoZXkgaGF2ZSBubyBUTFMNCiAg ICAgIHN1cHBvcnQgYXQgYWxsLg0KICAgICAgVGhlcmUgaXMgYSBwb3NzaWJseSBvZiBsZWdhY3kg c3lzdGVtcyBjb250YWluaW5nIFNTTCBpbXBsZW1lbnRhdGlvbnMNCiAgICAgIHRoYXQgYXJlIFRM UyBleHRlbnNpb25zIGludG9sZXJhbnQuDQogICAgICBUaGVyZSBpcyBhIHBvc3NpYmx5IG9mIFNT TCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjYW4gbmVnb3RpYXRlIFRMUywNCiAgICAgIGJ1dCBsZWdh Y3kgYXBwbGljYXRpb24ocykgdGhhdCBjYW4gbm90IGVuYWJsZSBpdCBvciBhbHdheXMgZm9yY2UN CiAgICAgIFNTTHYzIChkb21pbm8gZWZmZWN0KS4NCiAgICAgIENoYW5naW5nIHRoZSDigJxvbiB0 aGUgd2lyZeKAnSBwcm90b2NvbCB2ZXJzaW9uIGZyb20gU1NMdjMgdG8gVExTIGNvdWxkDQogICAg ICBjYXVzZSBoYW5kc2hha2VzIHRvIGJlIGJsb2NrZWQgYnkgYSB2YXJpZXR5IG9mIG5ldHdvcmsN CiAgICAgIGluZnJhc3RydWN0dXJlLg0KDQpJIGJlbGlldmUgYW4gaW1wZXJhdGl2ZSBmb3IgZGVw bG95aW5nIHRoaXMgZml4IGlzIGVuc3VyaW5nIHRoYXQgYnkgYXBwbHlpbmcNCnRoZSBmaXggbm8g dW53YW50ZWQgc2lkZSBlZmZlY3RzIG9jY3VyIHRoYXQgY291bGQgYnJlYWsgYSBjdXN0b21lcg0K cHJvZHVjdGlvbiBlbnZpcm9ubWVudCBhbmQgdGhhdCB0aGUgZml4IGlzIGFwcGxpY2FibGUgdG8g dGhlIGdyZWF0ZXN0DQphbW91bnQgb2YgdGhlIGluc3RhbGxlZCBiYXNlIGFzIHBvc3NpYmxlLg0K DQpUaGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgbm90ZSBpbiBTZWN0aW9uIDQgd291bGQgYmUgdXNl ZnVsIGluIGFkZHJlc3NpbmcNCnRoaXMgY29uY2VybjoNCg0KDQpOb3RlIDogQ2xpZW50cyB0aGF0 IHVzZSBlaXRoZXIgb2YgdGhlIHNpZ25hbGluZyBtZXRob2RzIE1VU1QgYmUgcHJlcGFyZWQgdG8N CmFjY2VwdCBhIFNlcnZlciByZXNwb25zZSBjb250YWluaW5nIHRoZSAgInJlbmVnb3RpYXRpb25f aW5mbyIgZXh0ZW5zaW9uDQp0cmFuc21pdHRlZCBpbiBhIFNlcnZlckhlbGxvIG1lc3NhZ2Ugd2l0 aCB0aGUgU1NMdjMgcHJvdG9jb2wgdmVyc2lvbiB7DQoweDAzLCAweDAwIH0gYW5kIE1VU1QgY29u dGludWUgd2l0aCBwcm90ZWN0ZWQgcmVuZWdvdGlhdGlvbnMgYXQgdGhpcw0KcHJvdG9jb2wgbGV2 ZWwuDQoNCg0KQWRkaXRpb25hbGx5LCBJIGJlbGlldmUgdGhhdCBhZGRpbmcgZXh0ZW5zaW9ucyBp biB0aGUgaW5pdGlhbCBDbGllbnRIZWxsbw0KY291bGQgcmVzdWx0IGluIGFkdmVyc2UgY3VzdG9t ZXIgZXZlbnRzIGluIHNvbWUgdmVyeSBzbWFsbCBudW1iZXIgb2YNCmVudmlyb25tZW50cyB0aGF0 IGFyZSBleHRlbnNpb25zIGludG9sZXJhbnQgWzFdLiAgVGhlIGZvbGxvd2luZyBhZGRpdGlvbmFs DQpub3RlIGluIFNlY3Rpb24gNSB3b3VsZCBiZSB1c2VmdWwgaW4gcHJvdmlkaW5nIGd1aWRhbmNl IGluIG1pdGlnYXRpbmcgdGhpcw0KY29uY2VybjoNCg0KDQpOb3RlIDogIEluIGNhc2VzIHdoZXJl IGEgQ2xpZW50SGVsbG8gcHJvdG9jb2wgYmVoYXZpb3IgY2hhbmdlIGZyb20gbm90DQpzZW5kaW5n IGV4dGVuc2lvbnMgdG8gc2VuZGluZyBleHRlbnNpb25zIGlzIGEgcmlzayB3aGVyZSBsZWdhY3kg U2VydmVycyBtYXkNCmV4aXN0IHRoYXQgYXJlIGV4dGVuc2lvbiBpbnRvbGVyYW50IHRoZW4gdGhl IENsaWVudCBNQVkgbWl0aWdhdGUgdGhpcyByaXNrDQpieSBzZW5kaW5nIHRoZSBUTFMgY2lwaGVy IHN1aXRlICJUTFNfUkVORUdPX1BST1RFQ1RJT05fUkVRVUVTVCIgYW5kIFNIT1VMRA0KTk9UIHNl bmQgdGhlICJyZW5lZ290aWF0aW9uX2luZm8iIGV4dGVuc2lvbiB1bmxlc3MgdGhlIENsaWVudCBp cyBzZW5kaW5nDQpvdGhlciBleHRlbnNpb25zLg0KDQpbMV0gVGhlIG9idmlvdXMgYW5zd2VyIGlz IHRvIHVwZ3JhZGUgdGhlIFRMUyBTZXJ2ZXJzIHRoYXQgYXJlIFRMUyBleHRlbnNpb24NCmludG9s ZXJhbnQsIGJ1dCB0aGlzIHJlYXNvbmluZyBoYXMgdGhlIGZvbGxvd2luZyBwaXRmYWxsczoNCg0K ICAgMS4gIFRoZXNlIFNlcnZlcnMgbWlnaHQgbm90IGJlIGlkZW50aWZpZWQgdW50aWwgYWZ0ZXIg dGhlIENsaWVudHMgaGF2ZQ0KICAgICAgIGJlZW4gdXBkYXRlZCBhbmQgd2hpbGUgdGhleSBhcmUg YmVpbmcgbG9jYXRlZCBhbmQgdXBkYXRlZCB0aGUNCiAgICAgICBwcm9kdWN0aW9uIGVudmlyb25t ZW50IGNvdWxkIGJlIGRvd24uDQogICAyLiAgVGhlc2UgU2VydmVycyBtaWdodCBiZSBvdXQgb2Yg c2VydmljZSBhcyBmYXIgYXMgU1cgdXBkYXRlcyBhcmUNCiAgICAgICBjb25jZXJuZWQgYW5kIHVu YWJsZSB0byBiZSB1cGRhdGVkLiAgRS5nLiB0aGUgb3JpZ2luYWwgU1cgdmVuZG9yIG5vDQogICAg ICAgbG9uZ2VyIGV4aXN0czsgbmV3ZXIgU1cgd2lsbCBubyBsb25nZXIgcnVuIG9uIHNhaWQgSFc7 IHRoZSBhYmlsaXR5DQogICAgICAgb2YgdGhlIHZlbmRvciB0byBidWlsZCBjb2RlIGZvciBzYWlk IGVudmlyb25tZW50IG5vIGxvbmdlciBleGlzdHMuDQogICAgICAgVGhpcyBhbGwgbWVhbnMgdGhh dCB0aGVzZSBTZXJ2ZXJzIGNhbiBub3QgYmUgdXBkYXRlZCBhbmQgd2lsbCByZW1haW4NCiAgICAg ICBUTFMgZXh0ZW5zaW9uIGludG9sZXJhbnQgdW50aWwgdGhlIGN1c3RvbWVyIGV2ZW50dWFsbHkg cmVwbGFjZXMNCiAgICAgICB0aGVzZSBzeXN0ZW1zLiAgQWRkaXRpb25hbGx5LCBleHBlcmllbmNl IGhhcyBzaG93biB0aGF0IHRoZXNlDQogICAgICAgc3lzdGVtcyBhcmUgbGlrZWx5IHRvIGJlIHZp dGFsIHBhcnRzIG9mIGN1c3RvbWVyIGluZnJhc3RydWN0dXJlIHRoYXQNCiAgICAgICBoYXZlIGJl ZW4gbG9uZyBvdmVybG9va2VkLg0KDQoNCi0gTWljayBHcmF5DQotIElCTQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRM U0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM= From Chris.Newman@Sun.COM Fri Dec 4 15:54: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 47B8E3A6A73 for ; Fri, 4 Dec 2009 15:54: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 0mwldNdbhgkW for ; Fri, 4 Dec 2009 15:54:32 -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 5C3AB3A6A6F for ; Fri, 4 Dec 2009 15:54:28 -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 nB4NsJHw014337 for ; Fri, 4 Dec 2009 15:54:19 -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 <0KU500D00JIPT700@fe-sfbay-10.sun.com> for tls@ietf.org; Fri, 04 Dec 2009 15:54:19 -0800 (PST) Received: from [10.1.110.5] ([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 <0KU500ASVJQG6QB0@fe-sfbay-10.sun.com>; Fri, 04 Dec 2009 15:54:18 -0800 (PST) Date: Fri, 04 Dec 2009 15:54:16 -0800 From: Chris Newman Sender: Chris.Newman@Sun.COM To: mrex@sap.com Message-id: <5B460507C5B45BE8C29D4E33@446E7922C82D299DB29D899F> X-Mailer: Mulberry/4.0.8 (Mac OS X) Cc: tls@ietf.org Subject: [TLS] backwards compatiblity philosophy and MCSV (was Re: Last Call: 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, 04 Dec 2009 23:54:33 -0000 --On December 2, 2009 20:30:09 +0100 Martin Rex wrote: > I wrote up my proposal after realizing that some people just did > not care about the obvious and serious disruptive nature for the > interoperability in productive environments and existing usage scenarios > of the original proposal which contained this: > > 4.3. SSLv3 > > SSLv3 does not support extensions and thus it is not possible to > securely renegotiate with SSLv3. The crux of the philosophical difference we are having is how we treat backwards compatibility. My position: 1. Backwards compatibility with IETF standards track RFCs is important. 2. Backwards compatibility with widely deployed critical software is important, although there are caveats if that software/maker demonstrated bad faith or if the accommodation mechanism is too expensive or heuristic. 3. Other forms of backwards compatibility are usually a bad thing. They create code bloat and specification complexity that increases maintenance cost, necessary domain expertise training costs, and allows the standard to drift away from a clean architecture into a jumble of special cases. Also rewarding vendors that ship incompliant implementations by accommodating them by default simply leads to more incompliant implementations and standards drift which is bad for consumers and the industry. I'm now convinced there's enough SSLv3 out there that it falls into category 2, so the old section 4.3 was not acceptable -- we at least need to allow the RI extension to be added to SSLv3 implementations. But extensions-intolerant servers fall into category 3 in my estimation unless I see compelling evidence they fall in category 2. I used to be more willing to move things to category 2 when doing design work. But after experiencing staff contractions during the tech bubble burst and recent recession, the cost of backwards compatibility baggage has become so clear to me that I set a high bar to put anything in category 2. Also I place a high value on extension mechanisms as every successful IETF protocol that lacked one eventually had to add it as a core protocol feature (POP, SMTP, TLS, LDAP, etc). A protocol without clean extensibility is at best mis-designed and the sooner that is fixed, the better for all consumers of the protocol. You seem to believe backwards compatibility is unquestionably a good thing, at least when fixing a security vulnerability. We disagree on that point and I'm not likely to change my philosophy given my experience. Right now I oppose MCSV but can live with the compromise in draft-ietf-tls-renegotiation-01 because I can choose not to generate that special case in my software and believe it will eventually go away. If you want my support for MCSV, provide sufficient evidence to convince me that extensions-intolerant SSLv3 servers fall into category 2. Otherwise we simply hold different positions and further discussion is pointless. - Chris From marsh@extendedsubset.com Fri Dec 4 17: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 3D7643A68D2 for ; Fri, 4 Dec 2009 17:20:24 -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 CVYlFK+-Cpo9 for ; Fri, 4 Dec 2009 17:20: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 8D95F3A659A for ; Fri, 4 Dec 2009 17:20: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 1NGjJe-000AKk-8I; Sat, 05 Dec 2009 01:20:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B9346603C; Sat, 5 Dec 2009 01:20: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: U2FsdGVkX181c+DqJsrVAjKMTqu2MUuoVYD2Gtdo42o= Message-ID: <4B19B53F.8050501@extendedsubset.com> Date: Fri, 04 Dec 2009 19:19:59 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Chris Newman References: <5B460507C5B45BE8C29D4E33@446E7922C82D299DB29D899F> In-Reply-To: <5B460507C5B45BE8C29D4E33@446E7922C82D299DB29D899F> 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] backwards compatiblity philosophy and MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2009 01:20:24 -0000 Chris Newman wrote: > > 1. Backwards compatibility with IETF standards track RFCs is important. > 2. Backwards compatibility with widely deployed critical software is > important, although there are caveats if that software/maker > demonstrated bad faith or if the accommodation mechanism is too > expensive or heuristic. > 3. Other forms of backwards compatibility are usually a bad thing. They > create code bloat and specification complexity that increases > maintenance cost, necessary domain expertise training costs, and allows > the standard to drift away from a clean architecture into a jumble of > special cases. Agree. > Also rewarding vendors that ship incompliant > implementations by accommodating them by default simply leads to more > incompliant implementations and standards drift which is bad for > consumers and the industry. It's just this one message, Client Hello, is a special case because it affects other systems as well. They get stuck in some slow failure timeout mode which is a fate worse than, well, a fast failure. It's a public health issue, like buying clean needles for junkies. Getting these patches widely deployed can only help to get these crusty old servers fixed or retired. The only way to ensure they're applied everywhere is if they don't have any upgrade-ordering dependency (see the recent great email from Michael Gray). > I'm now convinced there's enough SSLv3 out there that it falls into > category 2, so the old section 4.3 was not acceptable -- we at least > need to allow the RI extension to be added to SSLv3 implementations. > But extensions-intolerant servers fall into category 3 in my estimation > unless I see compelling evidence they fall in category 2. I would put an SSLv3 extension-intolerant server in category 2 along with SSLv3 itself. A server that negotiates to TLS though that doesn't at least ignore extensions properly? Category 3, but it needs to be patched anyway. > I used to be more willing to move things to category 2 when doing design > work. But after experiencing staff contractions during the tech bubble > burst and recent recession, the cost of backwards compatibility baggage > has become so clear to me that I set a high bar to put anything in > category 2. Brokenness is a luxury we can ill afford. > Also I place a high value on extension mechanisms as every > successful IETF protocol that lacked one eventually had to add it as a > core protocol feature (POP, SMTP, TLS, LDAP, etc). Good in the lessons learned department. > A protocol without > clean extensibility is at best mis-designed and the sooner that is > fixed, the better for all consumers of the protocol. It might be a little different for a crypto protocol. These things need to be reviewed and certified, and making things too easy to reconfigure on the fly or pass arbitrary data could raise questions. > You seem to believe backwards compatibility is unquestionably a good > thing, at least when fixing a security vulnerability. We disagree on > that point and I'm not likely to change my philosophy given my experience. I think most of us see the exceptional nature of these circumstances. The best philosophy in this case is adaptive pragmatism. > Right now I oppose MCSV but can live with the compromise in > draft-ietf-tls-renegotiation-01 because I can choose not to generate > that special case in my software and believe it will eventually go > away. If we make the right decisions now, eventually it will. > If you want my support for MCSV, provide sufficient evidence to > convince me that extensions-intolerant SSLv3 servers fall into category > 2. Here goes: > The SSL Protocol > Version 3.0 > draft-freier-ssl-version3-02.txt >... > INTERNET-DRAFT SSL 3.0 November 18, 1996 > > struct { > HandshakeType msg_type; /* handshake type */ > uint24 length; /* bytes in message */ > select (HandshakeType) { > case hello_request: HelloRequest; > case client_hello: ClientHello; > case server_hello: ServerHello; > case certificate: Certificate; > case server_key_exchange: ServerKeyExchange; > case certificate_request: CertificateRequest; > case server_hello_done: ServerHelloDone; > case certificate_verify: CertificateVerify; > case client_key_exchange: ClientKeyExchange; > case finished: Finished; > } body; > } Handshake; >... > The structure of the client hello is as follows. > struct { > ProtocolVersion client_version; > Random random; > SessionID session_id; > CipherSuite cipher_suites<2..2^16-1>; > CompressionMethod compression_methods<1..2^8-1>; > } ClientHello; >... > struct { > ProtocolVersion server_version; > Random random; > SessionID session_id; > CipherSuite cipher_suite; > CompressionMethod compression_method; > } ServerHello; These structures don't include any members for extension data. I don't know about others, but when start coding something like this, I like to copy and paste these definitions into my source file as line comments and use those comments to frame a struct definition or parsing code. So here's what developers had to read and implement in order to ignore Client Hello extensions: > 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) adds the sentence: > 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." * It's just a "compatibility note" outside the formal structure definitions. * No standard defines any structure for what the data might be, not even a simple TLV format with an experimental numbering range. So even though it says "it is permitted", still no one could use it. * To properly support this it could amount to skipping ~2**24 bytes (16MB) of data (uint24 length). Maybe later specs added some limitation, or I'm not finding it? I wonder how many implementations today are "fully standards-compliant" in this respect? * There's no provision for extra data after Server Hello, so there couldn't be any negotiation or confirmation of what you requested. * No structure for this "extra data" was defined until RFC 3546 (TLS Extensions) in June 2003 (6.5 years later). So TLS server implementations designed before about 2004 probably had no compliant clients with which to test that would send any data after the defined ClientHello structure. All pre-Vista Windows OS's may be in this category based on design date. > Otherwise we simply hold different positions and further discussion > is pointless. Anyone that got this perfect back in 1996, I say "well done". For those that didn't I have some sympathy. But for those servers that have waited 6 or 13 years to fix it, jeez! Well it's time to dust off that old compiler because we've got something here that really needs patch patching (and you'll probably need to add extension support). - Marsh From nelson@bolyard.me Fri Dec 4 17: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 941E23A67FD for ; Fri, 4 Dec 2009 17:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 NTi-Igl08kzV for ; Fri, 4 Dec 2009 17:50:24 -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 28FA13A63C9 for ; Fri, 4 Dec 2009 17:50:24 -0800 (PST) Received: (qmail 10157 invoked from network); 5 Dec 2009 01:50:14 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 05 Dec 2009 01:50:14 -0000 Message-ID: <4B19BC56.8070001@bolyard.me> Date: Fri, 04 Dec 2009 17:50: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 CC: IETF TLS Working Group References: <5B460507C5B45BE8C29D4E33@446E7922C82D299DB29D899F> <4B19B53F.8050501@extendedsubset.com> In-Reply-To: <4B19B53F.8050501@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] backwards compatiblity philosophy and MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2009 01:50:25 -0000 Chris Newman wrote: >> 1. Backwards compatibility with IETF standards track RFCs is important. >> 2. Backwards compatibility with widely deployed critical software is >> important, although there are caveats if that software/maker >> demonstrated bad faith or if the accommodation mechanism is too >> expensive or heuristic. >> 3. Other forms of backwards compatibility are usually a bad thing. They >> create code bloat and specification complexity that increases >> maintenance cost, necessary domain expertise training costs, and allows >> the standard to drift away from a clean architecture into a jumble of >> special cases. > > Agree. +1 [snip] >> I'm now convinced there's enough SSLv3 out there that it falls into >> category 2, so the old section 4.3 was not acceptable -- we at least >> need to allow the RI extension to be added to SSLv3 implementations. >> But extensions-intolerant servers fall into category 3 in my estimation >> unless I see compelling evidence they fall in category 2. I agree with Chris. On 2009-12-04 17:19 PST, Marsh Ray wrote: > I would put an SSLv3 extension-intolerant server in category 2 along > with SSLv3 itself. I wouldn't. [big snip] > Anyone that got this perfect back in 1996, I say "well done". > > For those that didn't I have some sympathy. > > But for those servers that have waited 6 or 13 years to fix it, jeez! Exactly! I had some sympathy for the ones that didn't get it perfect back in 1998, which is why some products that use NSS have fallback. But that was 11 years ago! My sympathy has long since run out. > Well it's time to dust off that old compiler because we've got something > here that really needs patch patching (and you'll probably need to add > extension support). At the very least, add the one line code change needed to ignore "extra data after the compression methods" in client hellos. From rms@gnu.org Fri Dec 4 22: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 1E82A3A68DA for ; Fri, 4 Dec 2009 22:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 DJjZH2ynkwpC for ; Fri, 4 Dec 2009 22:50:29 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 3C3093A67E1 for ; Fri, 4 Dec 2009 22:50:29 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NGoTC-0005DP-JS; Sat, 05 Dec 2009 01:50:18 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Marsh Ray In-reply-to: <4B172027.9030200@extendedsubset.com> (message from Marsh Ray on Wed, 02 Dec 2009 20:19:19 -0600) References: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp> <300574.25594.qm@web45507.mail.sp1.yahoo.com> <4AB3A5F6.1030202@earthlink.net> <4B15D9D2.3010107@stpeter.im> <4B15E2DD.3000701@extendedsubset.com> <4B172027.9030200@extendedsubset.com> Message-Id: Date: Sat, 05 Dec 2009 01:50:18 -0500 Cc: tglassey@earthlink.net, 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: 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: Sat, 05 Dec 2009 06:50:31 -0000 You suggested the hypothetical idea that a trademark on a magic sequence of bytes could enable someone to interfere with the use of a standard, and referred us to this page. http://www.chillingeffects.org/trademark/notice.cgi?NoticeID=203 That page concerns commercial labelling in the usual way. I don't think it relates to this issue. From djhopwood@googlemail.com Sat Dec 5 14:13: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 604553A6960 for ; Sat, 5 Dec 2009 14:13:45 -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 2KevJwh+XC2z for ; Sat, 5 Dec 2009 14:13:43 -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 D393B3A695E for ; Sat, 5 Dec 2009 14:13:42 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so153615eyd.51 for ; Sat, 05 Dec 2009 14:13: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=Eh+KdHdtsl1sesKjdcnVlxpzfl/DSQsUu2cprGngreU=; b=ls6lHKK04x63xCaTk+ebU+bCxFtjudh+q6fkWFnxWeVKvNJBG0imS4f60MvPbXWLJw po8lzS6VuqM2f5GxZeVoNR3n4M7zjF1z9r2JRJv8dch5VMBcest0sPwLAmGf0405Z6CK 3H4SxbQqb7XpfBmc4Wlh/3GPRpUJ8WpkQUuR4= 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=SWFYhc8SLU2xefLOHsI+IV+rgNoyoyzwbTT1r20BWWZ8FxiLvc66OZomGOMSJfz6B7 hXTySxeYWLNz7uNv8sXzV+so8VBBRWs3Dib4oIWjBo2VBwVXFuTP/srFQzRbomOoLhKN XgeqZGH/yd2NrONNlxxSkcjAjdTyb/R5sYjgs= Received: by 10.213.97.22 with SMTP id j22mr4835257ebn.53.1260051208586; Sat, 05 Dec 2009 14:13:28 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 13sm2596388ewy.13.2009.12.05.14.13.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Dec 2009 14:13:27 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1ADB0B.1050005@jacaranda.org> Date: Sat, 05 Dec 2009 22:13: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: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA7CC138DDCA75591B9991D98" Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation - deployment in legacy environments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2009 22:13:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7CC138DDCA75591B9991D98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael Gray wrote: > Note : Clients that use either of the signaling methods MUST be prepare= d to > accept a Server response containing the "renegotiation_info" extension= > transmitted in a ServerHello message with the SSLv3 protocol version { > 0x03, 0x00 } and MUST continue with protected renegotiations at this > protocol level. This is fine, although obvious. > Additionally, I believe that adding extensions in the initial ClientHel= lo > could result in adverse customer events in some very small number of > environments that are extensions intolerant [1]. The following additio= nal > note in Section 5 would be useful in providing guidance in mitigating t= his > concern: >=20 > Note : In cases where a ClientHello protocol behavior change from not > sending extensions to sending extensions is a risk where legacy Servers= may > exist that are extension intolerant then the Client MAY mitigate this r= isk > by sending the TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST" and SHO= ULD > NOT send the "renegotiation_info" extension unless the Client is sendin= g > other extensions. Strongly opposed. There is no justification for a SHOULD NOT-level statem= ent insisting that clients work around bugs in nonconformant servers. (Read t= he RFC 2119 definition of SHOULD NOT; it clearly doesn't apply.) Besides, it is incorrect to not send the RI extension in cases where it would have contained verify_data. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigA7CC138DDCA75591B9991D98 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/ iF4EAREIAAYFAksa2xMACgkQWUc8YzyzqAcIEAD+OHKcinn3DBhn+W7Yc1OwcZlC Emhye6+dAUaUsBLu2F4A/RRZ+uJ6oZ+GTdQh5xwwgj0p6DRvG/eQ3/08flqi90SF =5+Ex -----END PGP SIGNATURE----- --------------enigA7CC138DDCA75591B9991D98-- From rms@gnu.org Sat Dec 5 16:31: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 5B6EE3A6962 for ; Sat, 5 Dec 2009 16:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, GB_I_LETTER=-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 0MDvPrZCxZwO for ; Sat, 5 Dec 2009 16:31:24 -0800 (PST) Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by core3.amsl.com (Postfix) with ESMTP id 420F43A695D for ; Sat, 5 Dec 2009 16:31:24 -0800 (PST) Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NH51t-0000HG-Oz; Sat, 05 Dec 2009 19:31:13 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: Dean Anderson In-reply-to: (message from Dean Anderson on Fri, 4 Dec 2009 12:06:55 -0500 (EST)) References: Message-Id: Date: Sat, 05 Dec 2009 19:31:13 -0500 Cc: ietf-honest@lists.iadl.org, tglassey@earthlink.net, 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: 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: Sun, 06 Dec 2009 00:31:25 -0000 If you are actually refering to a Ford, then yes. But if you _called_ your thing a "Ford", then no. That's true, but it isn't the issue. The point is, Ford's trademark does not restrict using the four-letter combination "Ford" in general. A standard on "Open Systems" might have run afoul of Sun's trademark, had that term been successfully trademarked. Remember that we're talking about the idea that someone could claim a trademark on a sequence of bytes used as a magic code in a standard. naming a standard after someone's product is a different issue. Going back to the "Open Systems" example, if Sun hypothetically submits a standard naming something "Open Systems"; and we didn't notice the trademark; we approve the standard; later Sun comes around to the Standard users/implementers and says they are the only ones who can implement/use the standard using that name, and show the trademark documentation. Then it would seem that the IETF has endorsed Sun, and in anycase everyone else is screwed. You're talking about a different case, not the one we were talking about thus far. But ok, let's look at your case. All that would happen is that we would have to change the name of the standard. That shouldn't break any implementations. From mike-list@pobox.com Sat Dec 5 17: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 94D463A6947 for ; Sat, 5 Dec 2009 17:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUFFuqjHesSE for ; Sat, 5 Dec 2009 17:37:31 -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 D05033A677C for ; Sat, 5 Dec 2009 17:37: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 6404485A08 for ; Sat, 5 Dec 2009 20:37:20 -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=p+S/we0TMx6beHmohLMwgA8/e fw=; b=hKfuWE2RVRcQqFyehk8xSiQXClTIcT2CgkfWYups4irpLQUYeee6bmGx4 /dw1T/HNedqxRrbLfqjtwPO22+5lFzooWM7B3EMl//3Ra3XqdCDZ4y0SVRpWGPIz YwephJMJ6CzgRxRzXOniPA6TxRh7E9pn6hNqcjXLudOXgEEx/E= 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=Aw1etpt0RLt3DJlAlGK +i2IvBrsJCfiqHSdP5r4T2AJ3zm7keICj29VknwWwG/g193DES/c1HfcSM4zy/Or 4pGcXVfvSz3cB1Es+Uw4SK/pESGCJK1ZQJcNW2gfVwzWTs15Y/AybkJ8snDh3fnQ Xi0DeCLt0GPi258rmYrGL7lI= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 41BC485A07 for ; Sat, 5 Dec 2009 20:37: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 C9ECE85A06 for ; Sat, 5 Dec 2009 20:37:19 -0500 (EST) Message-ID: <4B1B0B3C.8020208@pobox.com> Date: Sat, 05 Dec 2009 17:39:08 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E4FF75CC-E207-11DE-87FC-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: [TLS] Getting People to Upgrade X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2009 01:37:32 -0000 Here's an idea for how to cause a mass upgrade to the next version of TLS: Stop calling it TLS (which no lay person has ever heard of) and revert back to calling it SSL (which is what all vendors market their products with anyway); bump up the major version, so that it is "SSL 4.0"; products will appear that prominently display that they support SSL 4.0. These products can warn users that "This site does not support SSL 4.0; are you sure you want to continue?" SSL 4.0 will become synonymous with security to most people, and soon they will be demanding it, choosing products that support it over those that don't. I think it just might work. Mike P.S. anyone know how AOL/Netscape would feel about this? A quick search for "SSL trademark" didn't seem to turn up anything From mrex@sap.com Sat Dec 5 19: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 9BFA43A683F for ; Sat, 5 Dec 2009 19:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 m+eAtSm0cOHO for ; Sat, 5 Dec 2009 19:24: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 6C6E03A67B3 for ; Sat, 5 Dec 2009 19:24:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB63O4RD013249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Dec 2009 04:24:04 +0100 (MET) From: Martin Rex Message-Id: <200912060324.nB63O3ll023763@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Sun, 6 Dec 2009 04:24:03 +0100 (MET) In-Reply-To: <4B1ADB0B.1050005@jacaranda.org> from "David-Sarah Hopwood" at Dec 5, 9 10:13: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] Last Call: draft-ietf-tls-renegotiation - deployment 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: Sun, 06 Dec 2009 03:24:16 -0000 David-Sarah Hopwood wrote: > > Michael Gray wrote: > > Note : Clients that use either of the signaling methods MUST be prepared to > > accept a Server response containing the "renegotiation_info" extension > > transmitted in a ServerHello message with the SSLv3 protocol version { > > 0x03, 0x00 } and MUST continue with protected renegotiations at this > > protocol level. > > This is fine, although obvious. I'm sorry, but this seems to be non-obvious to _some_ implementors. openssl-0.9.8-stable-SNAP-20091205 seems to already contain the original proposal vom EKR. It will _not_ look for extensions in ServerHello if the returned server_version is 0x03,0x00 ssl/s3_clnt.c:ssl3_get_server_hello() #ifndef OPENSSL_NO_TLSEXT /* TLS extensions*/ if (s->version > SSL3_VERSION && s->version != DTLS1_VERSION && s->version != DTLS1_BAD_VER) { if (!ssl_parse_serverhello_tlsext(s,&p,d,n, &al)) > > > Additionally, I believe that adding extensions in the initial ClientHello > > could result in adverse customer events in some very small number of > > environments that are extensions intolerant [1]. The following additional > > note in Section 5 would be useful in providing guidance in mitigating this > > concern: > > > > Note : In cases where a ClientHello protocol behavior change from not > > sending extensions to sending extensions is a risk where legacy Servers may > > exist that are extension intolerant then the Client MAY mitigate this risk > > by sending the TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST" and SHOULD > > NOT send the "renegotiation_info" extension unless the Client is sending > > other extensions. > > Strongly opposed. There is no justification for a SHOULD NOT-level statement > insisting that clients work around bugs in nonconformant servers. (Read the > RFC 2119 definition of SHOULD NOT; it clearly doesn't apply.) I disagree. The SHOULD NOT is perfectly ok in the described situation, and the justification, that you risk a connection abort is more than sufficient. Intentionally creating interop problems is always at least a SHOULD NOT. > > Besides, it is incorrect to not send the RI extension in cases where it > would have contained verify_data. No, it is not incorrect. It is just that TLS extension RI can not be made reliably interoperable with old SSLv3 servers which do renegotiate. The "least offending" thing for a client that implements draft-tls-renegotiation-02 and is talking to an old server is to "probe" on the renegotiation handshake also with the MCSV and determine a mismatch of the TLS extension RI data in the ServerHello with its own notion about the status of the session&renegotiation. -Martin From mrex@sap.com Sat Dec 5 20: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 40FBC3A659C for ; Sat, 5 Dec 2009 20:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.409 X-Spam-Level: X-Spam-Status: No, score=-5.409 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_OFF=1.574] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QziH4YH32Cpa for ; Sat, 5 Dec 2009 20:01: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 2FEF53A68BF for ; Sat, 5 Dec 2009 20:01:01 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB640ojS002971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Dec 2009 05:00:50 +0100 (MET) From: Martin Rex Message-Id: <200912060400.nB640oXZ025752@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Sun, 6 Dec 2009 05:00:50 +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] OpenSSL patch for draft-mrex-tls-secure-renegotiation-03.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, 06 Dec 2009 04:01:03 -0000 Hi, I have built a patch for openssl-0.9.8-stable-SNAP-20091205 that implements my draft-mrex-tls-secure-renegotiation-03.txt That OpenSSL code already contains incomplete code for the original EKR draft, so I just reused the last finished messages in s->s3. It's ~180 lines changed (~120 LoC -- counting every curly brace as a line -- OpenSSL style). that already includes a #else /* OPENSSL_NO_TLSEXT */ so that you get secure renegotiation based on my draft even when compiling openssl without TLSEXT code. And it could be slightly less, because the server and client can use the same code for the modified handshake message hash (code reuse, less code paths to test). I was to lazy to do that now, because I would have had to add a new function, and made that function accessible from s3_srvr.c and s3_clnt.c. The handling of the MCSV is slightly tricky, because of how creation of ClientHello.cipher_suites (on client) and parsing of ClientHello.cipher_suites (on server) is modularized in OpenSSL (I did it in ssl_cipher_list_to_bytes() and ssl_bytes_to_cipher_list() where the "SSL *s" handle is still available, doing it at a lower level would require to change the function parameters of the lower level functions). So bottom line it is that my proposal means roughly less than half of the code compared to an incomplete TLS extension RI implementation for a codebase that already contains TLS extensions code. For a codebase without TLS extensions, the gap is larger. Could it be that OpenSSL has run out of "OP" flags? Having that ALLOW_UNSAFE_LEGACY_RENEGOTIATION flag in the SSL_OP_ALL set which is described as "workarounds that should be rather harmless" sounds dangerous. SSL_OP_ALL is likely asserted by all servers. #define SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION 0x00000400L /* Disable SSL 3.0/TLS 1.0 CBC vulnerability workaround that was added * in OpenSSL 0.9.6d. Usually (depending on the application protocol) * the workaround is not needed. Unfortunately some broken SSL/TLS * implementations cannot handle it at all, which is why we include * it in SSL_OP_ALL. */ /* SSL_OP_ALL: various bug workarounds that should be rather harmless. * This used to be 0x000FFFFFL before 0.9.7. */ #define SSL_OP_ALL 0x00000FFFL -Martin From marsh@extendedsubset.com Sat Dec 5 20:19: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 85CE43A68D3 for ; Sat, 5 Dec 2009 20:19:33 -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 RWIsPUFqBoOb for ; Sat, 5 Dec 2009 20:19: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 874BD3A684A for ; Sat, 5 Dec 2009 20:19: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 1NH8ag-000F5q-Ry; Sun, 06 Dec 2009 04:19:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A219B6678; Sun, 6 Dec 2009 04:19:20 +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: U2FsdGVkX1949MJwWSvV49l2ewGwPFEsWKXyl43o1ls= Message-ID: <4B1B30C6.2080906@extendedsubset.com> Date: Sat, 05 Dec 2009 22:19:18 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912060324.nB63O3ll023763@fs4113.wdf.sap.corp> In-Reply-To: <200912060324.nB63O3ll023763@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] Last Call: draft-ietf-tls-renegotiation - deployment in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2009 04:19:33 -0000 (The quoting got too much for me, check archives for thread context.) The language in the TLS 1.0 and 1.1 specs is something like: > TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus, > supporting both is easy. TLS clients who wish to negotiate with such > older servers SHOULD ... Notice the conditional SHOULD there. It seems to support the view that successful negotiation with an SSLv3 server (especially a broken one) is not considered a MUST for a conformant TLS implementation. What if we adapt the proposed language thusly: Clients that wish to be compatible with the maximum number of older servers (including SSLv3 servers not supporting TLS), SHOULD signal using the special TLS cipher suite value rather than including an extension on the initial Client Hello. (Note that this does not apply to any subsequent Client Hello messages sent.) Any such client MUST be prepared to receive in response a Server Hello message of any negotiable version (subject to the usual rules) which contains the extension. Clients are not required to offer support back to SSLv3, but if they do, they MUST implement the behaviors described in this specification. - Marsh From ynir@checkpoint.com Sun Dec 6 13: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 8BB4C3A69C7 for ; Sun, 6 Dec 2009 13:04:04 -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 0LHfgd9Tk+l0 for ; Sun, 6 Dec 2009 13:04:03 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 26EC03A69C9 for ; Sun, 6 Dec 2009 13:03:46 -0800 (PST) X-CheckPoint: {4B1C1BBF-10002-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BB96729C00D; Sun, 6 Dec 2009 23:03:35 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A4BAD29C002; Sun, 6 Dec 2009 23:03:35 +0200 (IST) X-CheckPoint: {4B1C1BBE-10000-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 nB6L3YGo004109; Sun, 6 Dec 2009 23:03:35 +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, 6 Dec 2009 23:03:45 +0200 From: Yoav Nir To: " " Date: Sun, 6 Dec 2009 23:03:33 +0200 Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acp2t5jZgRWcBYYYSM6P+Elj4NpEVA== Message-ID: References: <808FD6E27AD4884E94820BC333B2DB774F3118C3CA@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB774F3118CFAF@NOK-EUMSG-01.mgdnok.nokia.com> <2D9C122C-23B4-4284-93B2-FFADF33798C4@checkpoint.com> <808FD6E27AD4884E94820BC333B2DB774F3128928A@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F3128928A@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 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: Sun, 06 Dec 2009 21:04:04 -0000 On Dec 4, 2009, at 3:29 PM, = wrote: > Yoav Nir wrote: >=20 >>> 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. >>=20 >> I think there should be some form of extension-less signaling from >> client to server, at least for SSLv3 and TLS 1.0 on the initial >> handshake.=20 >=20 > The current draft has exactly this (as far as I can tell) -- so > are you OK with that part (and agree that the remaining issue > is sending-or-not-sending verify_data over-the-wire), or are > you proposing changes to the signalling part, too?=20 >=20 > (From your other email on the same day, I got the impression > you were not happy with the signalling part either...)=20 I would like the signaling to be applicable in more situations (up to and i= ncluding TLS 1.0 at least, even if the Client Hello is proposing an upgrade= to TLS 1.2 or higher), but I agree that this should not delay publication = as long as this is available when you begin with SSLv3. From nelson@bolyard.me Sun Dec 6 16:21: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 574453A696C for ; Sun, 6 Dec 2009 16:21:34 -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 jO6UkAMO-Wy0 for ; Sun, 6 Dec 2009 16:21:33 -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 77AF03A695E for ; Sun, 6 Dec 2009 16:21:33 -0800 (PST) Received: (qmail 28466 invoked from network); 7 Dec 2009 00:21:23 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 07 Dec 2009 00:21:23 -0000 Message-ID: <4B1C4AF8.6060605@bolyard.me> Date: Sun, 06 Dec 2009 16:23:20 -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: <200912060324.nB63O3ll023763@fs4113.wdf.sap.corp> <4B1B30C6.2080906@extendedsubset.com> In-Reply-To: <4B1B30C6.2080906@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation - deployment in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 00:21:34 -0000 On 2009-12-05 20:19 PST, Marsh Ray wrote: > (The quoting got too much for me, check archives for thread context.) > > The language in the TLS 1.0 and 1.1 specs is something like: > >> TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus, >> supporting both is easy. TLS clients who wish to negotiate with such >> older servers SHOULD ... > > Notice the conditional SHOULD there. It seems to support the view that > successful negotiation with an SSLv3 server (especially a broken one) > is not considered a MUST for a conformant TLS implementation. Right, ESPECIALLY not a broken one. > What if we adapt the proposed language thusly: > > Clients that wish to be compatible with the maximum number of older > servers (including SSLv3 servers not supporting TLS), SHOULD signal > using the special TLS cipher suite value rather than including an > extension on the initial Client Hello. Not "rather than", but "in addition to". "Rather than" mandates fallback. > (Note that this does not apply to > any subsequent Client Hello messages sent.) Any such client MUST be > prepared to receive in response a Server Hello message of any negotiable > version (subject to the usual rules) which contains the extension. > Clients are not required to offer support back to SSLv3, but if they do, > they MUST implement the behaviors described in this specification. > > - Marsh From fweimer@bfk.de Mon Dec 7 00: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 065EC28C121; Mon, 7 Dec 2009 00:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=1.078, 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 D1-3s1j4jhn6; Mon, 7 Dec 2009 00:34:42 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 1993C3A6834; Mon, 7 Dec 2009 00:34:40 -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 1NHZ37-00058c-2P; Mon, 07 Dec 2009 09:34:29 +0100 Received: by bfk.de with local id 1NHZ37-0007Ty-82; Mon, 07 Dec 2009 08:34:29 +0000 To: Chris Newman References: <20091130153734.D44C63A6AA9@core3.amsl.com> From: Florian Weimer Date: Mon, 07 Dec 2009 08:34:29 +0000 In-Reply-To: (Chris Newman's message of "Tue\, 01 Dec 2009 23\:04\:43 -0800") Message-ID: <821vj7b2sq.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, 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, 07 Dec 2009 08:34:43 -0000 * Chris Newman: > This the most time-sensitive and security-critical IETF draft with > respect to impact on the Internet community that I have seen in 17 > years of IETF participation. Standard vendor response is to disable broken protocol features. This has been done countless times for core protocols, and I guess it would work here, too. Fixing the protocol is desirable, but there's still a backup plan. Let's not pretend otherwise. 8-) --=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 marsh@extendedsubset.com Mon Dec 7 01:29: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 8CFBF3A685D for ; Mon, 7 Dec 2009 01:29:16 -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 6kqAXPd96CQL for ; Mon, 7 Dec 2009 01:29:15 -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 CD6EC3A6967 for ; Mon, 7 Dec 2009 01:29:15 -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 1NHZtx-0008fg-Gy; Mon, 07 Dec 2009 09:29:05 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C1AC4603A; Mon, 7 Dec 2009 09:29:02 +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/R/j19C2M0bqATwQ5gThu7ojilScF33Rc= Message-ID: <4B1CCADD.20509@extendedsubset.com> Date: Mon, 07 Dec 2009 03:29:01 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Florian Weimer References: <20091130153734.D44C63A6AA9@core3.amsl.com> <821vj7b2sq.fsf@mid.bfk.de> In-Reply-To: <821vj7b2sq.fsf@mid.bfk.de> 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] 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, 07 Dec 2009 09:29:16 -0000 Florian Weimer wrote: > > Standard vendor response is to disable broken protocol features. This > has been done countless times for core protocols, and I guess it would > work here, too. Fixing the protocol is desirable, but there's still a > backup plan. Let's not pretend otherwise. 8-) No, there's not a backup plan if you've been selling systems that depend on TLS renegotiation for years and have a large installed base. Particularly if you get revenue from service contracts, you can't regress the functionality where a fix is technically possible. - Marsh From ynir@checkpoint.com Mon Dec 7 01:37: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 8FCE23A6A1B for ; Mon, 7 Dec 2009 01:37: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.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 Er6bpmswcbJc for ; Mon, 7 Dec 2009 01:37:23 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B0CA43A68E5 for ; Mon, 7 Dec 2009 01:37:22 -0800 (PST) X-CheckPoint: {4B1CCC58-10004-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B0C9E29C008; Mon, 7 Dec 2009 11:37:11 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 94B9A29C002; Mon, 7 Dec 2009 11:37:11 +0200 (IST) X-CheckPoint: {4B1CCC58-10000-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 nB79bAGo002199; Mon, 7 Dec 2009 11:37:11 +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, 7 Dec 2009 11:37:21 +0200 From: Yoav Nir To: Marsh Ray Date: Mon, 7 Dec 2009 11:37:09 +0200 Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: Acp3IN+gOVsGJwfXSgacBYeluDPMrA== Message-ID: <76CBAD18-6849-4DF0-8035-C7E96A2393D3@checkpoint.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> <821vj7b2sq.fsf@mid.bfk.de> <4B1CCADD.20509@extendedsubset.com> In-Reply-To: <4B1CCADD.20509@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] 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, 07 Dec 2009 09:37:25 -0000 On Dec 7, 2009, at 11:29 AM, Marsh Ray wrote: > Florian Weimer wrote: >>=20 >> Standard vendor response is to disable broken protocol features. This >> has been done countless times for core protocols, and I guess it would >> work here, too. Fixing the protocol is desirable, but there's still a >> backup plan. Let's not pretend otherwise. 8-) >=20 > No, there's not a backup plan if you've been selling systems that depend > on TLS renegotiation for years and have a large installed base. > Particularly if you get revenue from service contracts, you can't > regress the functionality where a fix is technically possible. That's true for SSL VPNs that have an option to login with a certificate. It's not true for all the eBusiness sites that are almost entirely based on= usernames and passwords, or even for most installations of SSL VPNs, where= they use either only usernames and passwords or that together with some 2-= factor authentication. By now we know that certificate authentication of HTTPS (that's about the o= nly good case we've seen for renegotiation) is pretty rare. From Pasi.Eronen@nokia.com Mon Dec 7 04:24: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 D903A3A6A32 for ; Mon, 7 Dec 2009 04:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ZqmvME3GF40W for ; Mon, 7 Dec 2009 04:24:39 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AC3193A6A2C for ; Mon, 7 Dec 2009 04:24:38 -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 nB7COGV8023273; Mon, 7 Dec 2009 14:24:23 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 14:24:16 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 14:24:17 +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, 7 Dec 2009 14:24:11 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 7 Dec 2009 13:24:10 +0100 From: To: Date: Mon, 7 Dec 2009 13:24:10 +0100 Thread-Topic: Defining "TLS channel" (Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer) Thread-Index: Acp0bOEovC0pybLyTw+ULB0VVmOpowCyGyfw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> References: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> In-Reply-To: <20091203221420.GZ773@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: 07 Dec 2009 12:24:12.0006 (UTC) FILETIME=[2EC5A860:01CA7738] X-Nokia-AV: Clean Cc: william.polk@nist.gov, tls@ietf.org Subject: Re: [TLS] Defining "TLS channel" (Re: Last Call: draft-ietf-tls-renegotiation (Transport Layer) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 12:24:39 -0000 Nicolas Williams wrote: > I hesitate to request any additional changes to draft-ietf-tls- > renegotiation given that the surrounding threads have been a horrible > DDoS on us all. But if there's any way to get into it a definition of > "TLS channel" in the RFC5056 sense, it'd be great if we could. >=20 > Alternatively, perhaps draft-altman-tls-channel-bindings, which defines > (or soon will) the term ought to update RFC5246. >=20 > I'm particularly interested in hearing from the Security ADs (cc'ed) > how important they think it is that we properly define the term "TLS > channel", and what vehicle is best for that purpose. >=20 > [*] Where we've had to grapple with how best to word a definition > of "TLS channel" -- a very painful excercise that led to Martin's > independent re-discovery of the re-negotiation vulnerability. Well, I think one thing we've learned here is that none of the reasonable-looking definitions of "TLS channel" are exactly what typical TLS libraries offer to applications (via their APIs -- and there's some variation between APIs, too). Also, different people seem to have somewhat different expectations what properties such a "channel" should have. For example, if the certificate of peer changes in renegotiation, is that just a different certificate for the same identity, or a different identity? Does the application need to determine which received application_data byte corresponds to which certificate? This may have implications on what exactly the channel in RFC5056 sense would be. Or it may not -- the questions "what kind of abstraction TLS libraries should provide to applications" and "what should be 'channel' in RFC5056 sense" are certainly related, but not the same. Either way, I don't think we need to answer the question about=20 RFC5056 "channel" in draft-ietf-tls-renegotiation. Draft-altman-tls- channel-bindings will have to say something about this, though. Best regards, Pasi From Pasi.Eronen@nokia.com Mon Dec 7 04:33: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 2FE463A680C for ; Mon, 7 Dec 2009 04:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 VH3ns1Nh9Vt6 for ; Mon, 7 Dec 2009 04:33:21 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 00E203A683D for ; Mon, 7 Dec 2009 04:33:20 -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 nB7CX3b2031128; Mon, 7 Dec 2009 14:33:08 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 14:33:03 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 14:33: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); Mon, 7 Dec 2009 14:32:58 +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; Mon, 7 Dec 2009 13:32:57 +0100 From: To: , Date: Mon, 7 Dec 2009 13:32:56 +0100 Thread-Topic: [TLS] Next steps for draft-ietf-tls-renegotiation Thread-Index: Acp06x81UTfrhZTWRI2oX6rBqAQ2hgCTRGSA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31A4F4BA@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F3128928A@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 4, 9 02:29:50 pm <200912041407.nB4E76dQ011303@fs4113.wdf.sap.corp> In-Reply-To: <200912041407.nB4E76dQ011303@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: 07 Dec 2009 12:32:58.0769 (UTC) FILETIME=[68BF5010:01CA7739] 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, 07 Dec 2009 12:33:22 -0000 Martin Rex wrote: > Think about the following scenario: >=20 > Updated TLS client establishes session with _old_ server. The old > server requests renegotiation and were still early in the transition > period, so the user really wants his client to allow that. >=20 > What should the TLS client send on the renegotiation ClientHello to > that old server? What if the client used an extension-less ClientHello > for the initial handshake? what if that old server is actually > extensions-intolerant? >=20 > So: what should that client send on the renegotiation handshake with > that server? Does the answer differ based on which kind of old > server that is? >=20 > The answer for my proposal is obvious, described in my document > and fully interoperable with the entire installed base. >=20 > The answer for TLS extension RI is not in that document, non-obvious > and will either be insecure or break interop for some scenarios. I agree that the answer is not in the document, and it's non-obvious, so something needs to be changed in the document. Best regards, Pasi From paul.hoffman@vpnc.org Mon Dec 7 08:00: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 3CF4B3A6853 for ; Mon, 7 Dec 2009 08:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.059, 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 ont8syCX5k3v for ; Mon, 7 Dec 2009 08:00:53 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 715113A681C for ; Mon, 7 Dec 2009 08:00:53 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nB7G0TZb035941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Dec 2009 09:00:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <76CBAD18-6849-4DF0-8035-C7E96A2393D3@checkpoint.com> References: <20091130153734.D44C63A6AA9@core3.amsl.com> <821vj7b2sq.fsf@mid.bfk.de> <4B1CCADD.20509@extendedsubset.com> <76CBAD18-6849-4DF0-8035-C7E96A2393D3@checkpoint.com> Date: Mon, 7 Dec 2009 08:00:27 -0800 To: Yoav Nir , Marsh Ray From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" 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, 07 Dec 2009 16:00:54 -0000 At 11:37 AM +0200 12/7/09, Yoav Nir wrote: >On Dec 7, 2009, at 11:29 AM, Marsh Ray wrote: > >> Florian Weimer wrote: >>> >>> Standard vendor response is to disable broken protocol features. This >>> has been done countless times for core protocols, and I guess it would >>> work here, too. Fixing the protocol is desirable, but there's still a >>> backup plan. Let's not pretend otherwise. 8-) >> >> No, there's not a backup plan if you've been selling systems that depend >> on TLS renegotiation for years and have a large installed base. >> Particularly if you get revenue from service contracts, you can't >> regress the functionality where a fix is technically possible. > >That's true for SSL VPNs that have an option to login with a certificate. ...*and* that option is being actively used, *and* the settings cause reauthentication during the lifetime of a user session. Having tested many SSL VPNs, I strongly suspect the number of affected end users is quite small. --Paul Hoffman, Director --VPN Consortium From s@pahtak.org Mon Dec 7 02: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 806A93A6A22; Mon, 7 Dec 2009 02:31: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4vOV1RdDAH3; Mon, 7 Dec 2009 02:31:41 -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 5E53728C141; Mon, 7 Dec 2009 02:31:41 -0800 (PST) Received: by yxe30 with SMTP id 30so4514989yxe.29 for ; Mon, 07 Dec 2009 02:31:28 -0800 (PST) Received: by 10.91.161.32 with SMTP id n32mr123059ago.80.1260181888661; Mon, 07 Dec 2009 02:31:28 -0800 (PST) Received: from lonely.pahtak.org (ip68-107-82-55.sd.sd.cox.net [68.107.82.55]) by mx.google.com with ESMTPS id 15sm2486033yxh.4.2009.12.07.02.31.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 02:31:27 -0800 (PST) Received: from dualg5.pahtak.org (dualg5.pahtak.org [192.168.1.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by lonely.pahtak.org (Postfix) with ESMTPSA id 793605C019; Mon, 7 Dec 2009 02:31:24 -0800 (PST) Message-Id: <045EE96E-028E-4F09-9D6D-652DE6BD545E@pahtak.org> From: Steve Checkoway To: ietf@ietf.org In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com> Content-Type: multipart/signed; boundary=Apple-Mail-16-554326000; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 02:31:23 -0800 References: <20091130153734.D44C63A6AA9@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 07 Dec 2009 08:13:16 -0800 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, 07 Dec 2009 10:36:04 -0000 --Apple-Mail-16-554326000 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 30, 2009, at 7:37 AM, 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 I support this draft. -- Steve Checkoway --Apple-Mail-16-554326000 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGGTCCAtIw ggI7oAMCAQICECjZEESO561wLe6hSYyS4IQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDkyNTA2MTQwNVoXDTEwMDkyNTA2MTQw NVowPjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMc0Bw YWh0YWsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7p9cy3FSDC8pQp2wZJk szOqOD5o56n9IXludNRnvM1qxXy/axIE5oFiJvrOEB4fZhMiuP8HAM74NJqUGSTl3aNXBVgwVRbW i+COSpfmObxiK3UFA/T2sn6cPLpJEFjY5TvekVEKLNAi2k4iIUw8BreHWZ1xnGAUA6Z/UbQoHI6c Vl/Rcu1dWNWTwCyUNYwX09JMFu0B9RQ09ltiZhjDurUG9Zt2qSIy8G4ptEtlYqibL2ugs0wW/Hkf PQadgqlt5V52WOFtObn+dcJxvnZ2b8goUaFRHaALidyEARSUJoZRrj0rCKOIkLhH8oU5bfoJ1X5p BaW/w5rU5WqfrEIC2QIDAQABoykwJzAXBgNVHREEEDAOgQxzQHBhaHRhay5vcmcwDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQUFAAOBgQA5NBSpsqBLU41YA9IQ8Ojqz5K7MSyVo2q3Amv/pQlmyPxw tAWfAeujwxgeZ1hlfLDWotLOkUr1QJDY+ouRg1c7v0hwdOrr1WYF2as/7XY3i7sJE9WxNbBbm8rc u5/OMrbIwb+JH4fX/EhzAZtUJfNqkoUIg9zSW8kESEJP/Gr+oTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQKNkQRI7nrXAt7qFJjJLghDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMDcxMDMxMjRaMCMGCSqGSIb3 DQEJBDEWBBSjqWYQcL606+vAfsTvAHT5JoRCujCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECjZEESO561wLe6hSYyS4IQwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC ECjZEESO561wLe6hSYyS4IQwDQYJKoZIhvcNAQEBBQAEggEAaqR54wb0HSj8MohQ9jORq4Ixmd7Q b2U+lzfqkDDRQb12gvFL8cG0R7qQ5Y8Anmcq+YX+tAMqQllJ/p/ck2gSaPZgU68Jt4TqJBwQGDWF dVP8tN5wlmMCMpaVZJmFckZOZpqJkkClccn96JlvSAWFDIsupOHT3kDF/IgI6NAR8wk9rRkr2OAQ 6DGBy/u07hhqvnI3M6iOWYVoTV8dwLuZvCnrKXbgmO17HLLLf7wi+0fiOeWt1/k0Z0edY8xKB072 RhtpxOziz0p53x7XVEPGOsJdF8hm3+mOTK+MZqr4/+RObRtVU5yzAHidwO4Mi4CtXqZ0e1gAiCWY KUtO47hLDAAAAAAAAA== --Apple-Mail-16-554326000-- From dispensa@phonefactor.com Mon Dec 7 08:22: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 34C2128C1B8 for ; Mon, 7 Dec 2009 08:22: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 m4gd0nQuoMkT for ; Mon, 7 Dec 2009 08:22:44 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 1FB4328C1B7 for ; Mon, 7 Dec 2009 08:22:44 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKSx0ryRAbCGtqQEr7jQPmauesXeBUZsl8@postini.com; Mon, 07 Dec 2009 08:22:34 PST Received: from 10.10.10.73 ([10.10.10.73]) by pos-exch1.corp.positivenetworks.net ([204.13.120.8]) with Microsoft Exchange Server HTTP-DAV ; Mon, 7 Dec 2009 16:20:19 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 07 Dec 2009 10:22:32 -0600 From: Steve Dispensa To: Paul Hoffman , Yoav Nir , Marsh Ray Message-ID: Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard Thread-Index: Acp3WXo7KknEuopZxE+YMQq7XJ8pAg== 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] 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, 07 Dec 2009 16:22:45 -0000 On 12/7/09 10:00 AM, "Paul Hoffman" wrote: > At 11:37 AM +0200 12/7/09, Yoav Nir wrote: >> On Dec 7, 2009, at 11:29 AM, Marsh Ray wrote: >>> >>> No, there's not a backup plan if you've been selling systems that depend >>> on TLS renegotiation for years and have a large installed base. >>> Particularly if you get revenue from service contracts, you can't >>> regress the functionality where a fix is technically possible. >> >> That's true for SSL VPNs that have an option to login with a certificate. > > ...*and* that option is being actively used, *and* the settings cause > reauthentication during the lifetime of a user session. Having tested many SSL > VPNs, I strongly suspect the number of affected end users is quite small. That agrees with my experience, but I don't think SSL VPN's are the main issue. There are other cases for certificates - terminal services, web services, SSO systems, smart cards, lord knows what else. These are all minority cases, but they're out there. The point isn't that there's one huge use case for certificates (although there certainly are meaningfully large implementations of some of these technologies). Rather, the point is that client certs have been used in a variety of deployment scenarios for quite a few years now, and, ironically, by those who took particular care to secure their implementations (indicating the value of what they're protecting). Also, while it's arguable as to how useful it is, I suspect a lot of sites out there are still running with varying cryptographic strength requirements. This was trivially easy to repro against current Apache with a .htaccess file. -Steve From Nicolas.Williams@sun.com Mon Dec 7 08: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 4FE0C3A68E6 for ; Mon, 7 Dec 2009 08:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=0.165, 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 7DeKVnwBwBvG for ; Mon, 7 Dec 2009 08:49:26 -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 2D86B3A68A6 for ; Mon, 7 Dec 2009 08:49:26 -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 nB7GnGNC029432 for ; Mon, 7 Dec 2009 16:49:16 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 nB7GnFke026479 for ; Mon, 7 Dec 2009 09:49: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 nB7GbTMu010883; Mon, 7 Dec 2009 10:37:29 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7GbSY2010882; Mon, 7 Dec 2009 10:37:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 10:37:28 -0600 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20091207163728.GH773@Sun.COM> References: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.7i Cc: william.polk@nist.gov, tls@ietf.org Subject: Re: [TLS] Defining "TLS channel" (Re: Last Call: draft-ietf-tls-renegotiation (Transport Layer) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 16:49:27 -0000 On Mon, Dec 07, 2009 at 01:24:10PM +0100, Pasi.Eronen@nokia.com wrote: > Well, I think one thing we've learned here is that none of the > reasonable-looking definitions of "TLS channel" are exactly what > typical TLS libraries offer to applications (via their APIs -- and > there's some variation between APIs, too). None is a a strong word, but even if that's true: all the more reason to add a proper definition sooner rather than later, so that implementors will add the required APIs. > Also, different people seem to have somewhat different expectations > what properties such a "channel" should have. For example, if the > certificate of peer changes in renegotiation, is that just a different > certificate for the same identity, or a different identity? Does the > application need to determine which received application_data byte > corresponds to which certificate? If the re-negotiation bug is fixed then I'd say that re-negotiation does not change the channel (same as in SSHv2, which never had this bug). If the re-negotiation bug is NOT fixed then I'd say that re-negotiation does change the channel. > This may have implications on what exactly the channel in RFC5056 > sense would be. Or it may not -- the questions "what kind of > abstraction TLS libraries should provide to applications" and "what > should be 'channel' in RFC5056 sense" are certainly related, but not > the same. If we wanted to believe that re-negotiation replaces an existing channel with a different one then we wouldn't consider the re-negotiation bug a bug. Ergo I believe that RFC5056 is correct. > Either way, I don't think we need to answer the question about > RFC5056 "channel" in draft-ietf-tls-renegotiation. Draft-altman-tls- > channel-bindings will have to say something about this, though. draft-altman-tls-channel-bindings must say something about this. What I'm asking though, is for draft-altman-tls-channel-bindings to UPDATE RFC5246, if it is going to be the vehicle for adding a definition of TLS channel. Nico -- From gwz@net-zen.net Mon Dec 7 11:11: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 C05003A690F for ; Mon, 7 Dec 2009 11:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGSrHN2wg2kH for ; Mon, 7 Dec 2009 11:11:19 -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 8AC303A68DF for ; Mon, 7 Dec 2009 11:11:19 -0800 (PST) Received: (qmail 10216 invoked from network); 7 Dec 2009 19:11:07 -0000 Received: from unknown (24.22.129.187) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 07 Dec 2009 19:11:07 -0000 From: "Glen Zorn" To: "'Steve Checkoway'" , References: <20091130153734.D44C63A6AA9@core3.amsl.com> <045EE96E-028E-4F09-9D6D-652DE6BD545E@pahtak.org> In-Reply-To: <045EE96E-028E-4F09-9D6D-652DE6BD545E@pahtak.org> Date: Mon, 7 Dec 2009 11:10:45 -0800 Organization: Network Zen Message-ID: <006f01ca7770$fb067f70$f1137e50$@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: Acp3bCjoPG8TMwsrQa2EDK9s0YC8oQABMLLQ Content-Language: en-us X-Mailman-Approved-At: Mon, 07 Dec 2009 11:12:09 -0800 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, 07 Dec 2009 19:11:20 -0000 > On Nov 30, 2009, at 7:37 AM, 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 > > > I support this draft. Ditto. > > -- > Steve Checkoway > > > From djhopwood@googlemail.com Mon Dec 7 13: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 731D628C1EF for ; Mon, 7 Dec 2009 13:17:38 -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 qZc03caJWPfY for ; Mon, 7 Dec 2009 13:17:37 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 80FF528C1EA for ; Mon, 7 Dec 2009 13:17:35 -0800 (PST) Received: by ewy3 with SMTP id 3so34236ewy.13 for ; Mon, 07 Dec 2009 13:17: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=zEdrZb1nWRi7pUh+ITWKFFPhZlsNabIZPfNbk2UHKWs=; b=fV0G3u9o8tPpP5ewKkYYRYmuWdKYRxRf1vQRGCu3/cGbx+nyJ6cr5UtiSMyDAfr3sa Bs16pPRjQW8EXQ1fKoX/J0RR3tL4L4tT6TYOQ7SL4USzASM+F8QerqAAIfK+EtQJxqDq UG78MJW5rs1hYOXWdXhlTgGQ5/9r2HB42ufoo= 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=Htk6dZeJor/NXhvB4YHDPws6SUcKrhw3sYcf8z6y9nJYecPXTSn8cKJeQBwkM4lkjv /kf7l3G/3/SDoOTSHd5qOdVYBYN3zzgPYOvDa0ysPs066Xqybakf4Wcm7lXW8S6Fy094 ylZ3tokJKq9VR3WNqDerteS4pDS73VIJ0ytUw= Received: by 10.213.2.75 with SMTP id 11mr141169ebi.9.1260220625488; Mon, 07 Dec 2009 13:17:05 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 15sm3625196ewy.0.2009.12.07.13.17.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 13:17:05 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1D70D8.3070108@jacaranda.org> Date: Mon, 07 Dec 2009 21:17:12 +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: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9C53B997BD3C5EC80CE6D82C" Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 21:17:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9C53B997BD3C5EC80CE6D82C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pasi.Eronen@nokia.com wrote: > Nicolas Williams wrote: >=20 >> I hesitate to request any additional changes to draft-ietf-tls- >> renegotiation given that the surrounding threads have been a horrible >> DDoS on us all. But if there's any way to get into it a definition of= >> "TLS channel" in the RFC5056 sense, it'd be great if we could. >> >> Alternatively, perhaps draft-altman-tls-channel-bindings, which define= s >> (or soon will) the term ought to update RFC5246. >> >> I'm particularly interested in hearing from the Security ADs (cc'ed) >> how important they think it is that we properly define the term "TLS >> channel", and what vehicle is best for that purpose. >> >> [*] Where we've had to grapple with how best to word a definition >> of "TLS channel" -- a very painful excercise that led to Martin's >> independent re-discovery of the re-negotiation vulnerability. >=20 > Well, I think one thing we've learned here is that none of the > reasonable-looking definitions of "TLS channel" are exactly what > typical TLS libraries offer to applications (via their APIs -- and > there's some variation between APIs, too). I would expect a definition of "TLS channel" to inform the design of new APIs or API abstractions. I wouldn't expect it to change existing abstractions in current APIs, except possibly those that already have an abstraction that almost-but-not-quite corresponds to a TLS channel, and where the change to make it exactly correspond can be done compatibly= =2E > Also, different people seem to have somewhat different expectations > what properties such a "channel" should have. For example, if the > certificate of peer changes in renegotiation, is that just a different > certificate for the same identity, or a different identity? Does the > application need to determine which received application_data byte > corresponds to which certificate? The abstraction of "channel" most useful for understanding the attack and the authentication properties of TLS, is one such that every completed handshake begins a new channel -- whether or not there are changes in identity information, and independent of whether the handshake is abbreviated or full. (I was mistaken in claiming earlier that only full handshakes should be considered to start a new channel. Any pair of Finished messages creates a new channel identifier, and therefore should be considered to create a new channel.) > Either way, I don't think we need to answer the question about=20 > RFC5056 "channel" in draft-ietf-tls-renegotiation. I disagree; the draft currently uses the term "channel" in the Introduction without defining it. It does reference draft-altman-tls-channel-bindings, but this isn't sufficient to define the term because 'It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."'. The draft could, however, informatively cite RFC5056. I think it should. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig9C53B997BD3C5EC80CE6D82C 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/ iF4EAREIAAYFAksdcOIACgkQWUc8YzyzqAcfFgD/TVzh+cBLHb9akHHfbZyeFcw5 G+tsFv59T0ptuDxcwIgA/jv8IBDDblWWurFJgyB5mHyUJfCPNWsrryfbWgeug0pz =04dl -----END PGP SIGNATURE----- --------------enig9C53B997BD3C5EC80CE6D82C-- From djhopwood@googlemail.com Mon Dec 7 13:32: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 5FEB73A67C0 for ; Mon, 7 Dec 2009 13:32:51 -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 s5DChRnvE97I for ; Mon, 7 Dec 2009 13:32:50 -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 E61E33A67B0 for ; Mon, 7 Dec 2009 13:32:49 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so520637eyd.51 for ; Mon, 07 Dec 2009 13:32: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=R+MbFxeOGent7WlNdadxxrNueB1kX89HdYpVSBU4UHY=; b=WK/HiwLZG/y3KeXdg/l3VrmuBPHGDwD7LTRE2cQFSzsKhaiswmYEQpB8KaRNWoTKWG xszdeIHqs4Jt7ltHs+djZKRl69MuMwixM+MNoMPvpC9GPqyDJJtUQjOebGjbPO2fC17k OudsJ07I6lgDrBq6dnMuk5zr29SPd5mzUaFSc= 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=H/aPs21XWx0uRcRZAr2Ig8KWff355Z/oM3JRmhbJbDCptBkOcM2xeK24Ub4zrOTZbG RtakLb8WQ6HeBtpTCGBZBdjtLBh/7Ivs4pzDTZjt3g28KKB443Yll4wqdj/ZSpXhoMdp DBoZA3Vbcr0ejqmtRTmGhLQ8ORnDjhm5jzVuY= Received: by 10.213.37.73 with SMTP id w9mr6620641ebd.27.1260221556760; Mon, 07 Dec 2009 13:32:36 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 24sm9756572eyx.22.2009.12.07.13.32.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 13:32:36 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1D747E.1080001@jacaranda.org> Date: Mon, 07 Dec 2009 21:32: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: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> <20091207163728.GH773@Sun.COM> In-Reply-To: <20091207163728.GH773@Sun.COM> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA411BAA03EA51B6B5345DF73" Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 21:32:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA411BAA03EA51B6B5345DF73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 01:24:10PM +0100, Pasi.Eronen@nokia.com wrote: >> Well, I think one thing we've learned here is that none of the >> reasonable-looking definitions of "TLS channel" are exactly what >> typical TLS libraries offer to applications (via their APIs -- and >> there's some variation between APIs, too). >=20 > None is a a strong word, but even if that's true: all the more reason t= o > add a proper definition sooner rather than later, so that implementors > will add the required APIs. I agree. >> Also, different people seem to have somewhat different expectations >> what properties such a "channel" should have. For example, if the >> certificate of peer changes in renegotiation, is that just a different= >> certificate for the same identity, or a different identity? Does the >> application need to determine which received application_data byte >> corresponds to which certificate? >=20 > If the re-negotiation bug is fixed then I'd say that re-negotiation doe= s > not change the channel (same as in SSHv2, which never had this bug). >=20 > If the re-negotiation bug is NOT fixed then I'd say that re-negotiation= > does change the channel. I think this is a misunderstanding of the RFC5056 concept of "channel". Channel binding makes one channel cryptographically dependent on another;= it does not identify them. >> This may have implications on what exactly the channel in RFC5056 >> sense would be. Or it may not -- the questions "what kind of >> abstraction TLS libraries should provide to applications" and "what >> should be 'channel' in RFC5056 sense" are certainly related, but not >> the same. >=20 > If we wanted to believe that re-negotiation replaces an existing channe= l > with a different one then we wouldn't consider the re-negotiation bug a= > bug. Yes, we would, because: - the channels are not bound, and they should be (even if they are presented to an application as separate streams). - most TLS libraries present the channels as a single stream, and so applications using those libraries are vulnerable regardless of how many channel instances we should understand there to be. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigA411BAA03EA51B6B5345DF73 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/ iF4EAREIAAYFAksddIUACgkQWUc8YzyzqAfh9QEAn53kMYSkOPWG4L86dQlxGFi/ qIXOQyJhEowjuqui9dsA/RQspfXflD1PXxZW/nrP7dvcmFJeMiMzXUMetGsjSCSx =sTsq -----END PGP SIGNATURE----- --------------enigA411BAA03EA51B6B5345DF73-- From Nicolas.Williams@sun.com Mon Dec 7 13:38: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 DA6F628C0E9 for ; Mon, 7 Dec 2009 13:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.164, 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 PvvNZzcCz9as for ; Mon, 7 Dec 2009 13:38:55 -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 D80D928C0E4 for ; Mon, 7 Dec 2009 13:38:55 -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 nB7LcjmQ013790 for ; Mon, 7 Dec 2009 21:38:45 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 nB7LcjRH018463 for ; Mon, 7 Dec 2009 14:38: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 nB7LQwNn001039; Mon, 7 Dec 2009 15:26:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7LQwNY001038; Mon, 7 Dec 2009 15:26:58 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 15:26:57 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091207212656.GK861@Sun.COM> References: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> <4B1D70D8.3070108@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1D70D8.3070108@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 21:38:56 -0000 On Mon, Dec 07, 2009 at 09:17:12PM +0000, David-Sarah Hopwood wrote: > Pasi.Eronen@nokia.com wrote: > > Well, I think one thing we've learned here is that none of the > > reasonable-looking definitions of "TLS channel" are exactly what > > typical TLS libraries offer to applications (via their APIs -- and > > there's some variation between APIs, too). > > I would expect a definition of "TLS channel" to inform the design of > new APIs or API abstractions. I wouldn't expect it to change existing > abstractions in current APIs, except possibly those that already have > an abstraction that almost-but-not-quite corresponds to a TLS channel, > and where the change to make it exactly correspond can be done compatibly. Look at draft-altman-tls-channel-bindings. The impact on APIs is really rather trivial. All APIs will have some sort of handle to a TLS connection. A connection is almost a channel. From a connection you need a way to extract the channel bindings. Now, the only question is: is a series of connections resulting from re-negotiations one channel? Or is a channel == to a connection? (Here I'm using "connection" to mean something that's barely referred by that name in RFC5246, but which is: the state established by a TLS handshake and the record layer messages exchanged under its protection.) SSHv2 also does re-negotiations, but with proper binding of re-negotiations to the prior state. SSHv2 even has a proper unique channel binding: SSHv2 session IDs (which are derived by hashing all negotiation and key exchange messages). The SSHv2 session ID does not change even when re-negotiations occur. >From an RFC5056 point of view, the SSHv2 view is the correct one. The application sets up a channel, runs some additional application-layer authentication mechanism over that channel with channel binding to that channel, and then proceeds. It would be most unfortunate if after the authentication + channel binding operation the channel could be replaced, without the app's knowledge, with another one that might have an MITM. > > Also, different people seem to have somewhat different expectations > > what properties such a "channel" should have. For example, if the > > certificate of peer changes in renegotiation, is that just a different > > certificate for the same identity, or a different identity? Does the > > application need to determine which received application_data byte > > corresponds to which certificate? > > The abstraction of "channel" most useful for understanding the attack > and the authentication properties of TLS, is one such that every > completed handshake begins a new channel -- whether or not there are > changes in identity information, and independent of whether the > handshake is abbreviated or full. For understanding the attack, yes. But see below. > (I was mistaken in claiming earlier that only full handshakes should > be considered to start a new channel. Any pair of Finished messages > creates a new channel identifier, and therefore should be considered > to create a new channel.) Prior to fixing the re-negotiation vulnerability we should have considered each negotiation as resulting in a separate channel: then applying channel binding as an analysis tool would have made the MITM problem instantly apparent. Following the fix to the re-negotiation vulnerability I think we should say that the first negotiation establishes a channel and that the subsequent ones do not, just as in SSHv2. > > Either way, I don't think we need to answer the question about > > RFC5056 "channel" in draft-ietf-tls-renegotiation. > > I disagree; the draft currently uses the term "channel" in the > Introduction without defining it. It does reference > draft-altman-tls-channel-bindings, but this isn't sufficient > to define the term because 'It is inappropriate to use > Internet-Drafts as reference material or to cite them other than > as "work in progress."'. > > The draft could, however, informatively cite RFC5056. I think it > should. I don't care which I-D introduces a proper definition of "TLS channel", but I do care to see RFC5246 updated by whichever I-D does it. Nico -- From Nicolas.Williams@sun.com Mon Dec 7 13: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 CE04D3A697D for ; Mon, 7 Dec 2009 13:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.160, 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 8nRubO-8ErSR for ; Mon, 7 Dec 2009 13:49:14 -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 E4A883A672E for ; Mon, 7 Dec 2009 13:49:13 -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 nB7Ln1k9004095 for ; Mon, 7 Dec 2009 21:49:01 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 nB7Ln1nj024599 for ; Mon, 7 Dec 2009 14:49:01 -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 nB7LbEKi001187; Mon, 7 Dec 2009 15:37:14 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7LbDR3001186; Mon, 7 Dec 2009 15:37:13 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 15:37:12 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091207213712.GM861@Sun.COM> References: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> <20091207163728.GH773@Sun.COM> <4B1D747E.1080001@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1D747E.1080001@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 21:49:14 -0000 On Mon, Dec 07, 2009 at 09:32:46PM +0000, David-Sarah Hopwood wrote: > Nicolas Williams wrote: > > If the re-negotiation bug is fixed then I'd say that re-negotiation does > > not change the channel (same as in SSHv2, which never had this bug). > > > > If the re-negotiation bug is NOT fixed then I'd say that re-negotiation > > does change the channel. > > I think this is a misunderstanding of the RFC5056 concept of "channel". > Channel binding makes one channel cryptographically dependent on another; > it does not identify them. There's "channel binding" the action (this is verb-like) and "channel bindings" the data (this is noun-like). The data is very much like a name for a channel: o Channel bindings: [See historical note below.] Generally, some data that "names" a channel or one or both of its end-points such that if this data can be shown, at a higher network layer, to be the same at both ends of a channel, then there are no MITMs between the two end-points at that higher network layer. This term is used as a noun. (That's from RFC5056, page 5. See also [Lampson91].) > >> This may have implications on what exactly the channel in RFC5056 > >> sense would be. Or it may not -- the questions "what kind of > >> abstraction TLS libraries should provide to applications" and "what > >> should be 'channel' in RFC5056 sense" are certainly related, but not > >> the same. > > > > If we wanted to believe that re-negotiation replaces an existing channel > > with a different one then we wouldn't consider the re-negotiation bug a > > bug. > > Yes, we would, because: > > - the channels are not bound, and they should be (even if they are > presented to an application as separate streams). Following the fix they will be! The fact that they aren't bound *is* the bug in re-negotiation that we're fixing. > - most TLS libraries present the channels as a single stream, and so > applications using those libraries are vulnerable regardless of how > many channel instances we should understand there to be. Not really. If the individual connections are chained by channel binding, then the application need only make sure that they don't mix them up (they have to anyways, in order to interop at all). It should suffice that the TLS implementation chained all those connection by channel binding them as described in whatever proposed solution to the re-neg vuln becomes the proposed standard. Nico -- From ekr@networkresonance.com Mon Dec 7 14:01: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 A5A243A694E for ; Mon, 7 Dec 2009 14:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.928 X-Spam-Level: X-Spam-Status: No, score=0.928 tagged_above=-999 required=5 tests=[AWL=0.033, 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, 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 NTmBoLoAca3t for ; Mon, 7 Dec 2009 14:01:09 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id ED1CD3A6919 for ; Mon, 7 Dec 2009 14:01:08 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id DA1A06C5242 for ; Mon, 7 Dec 2009 14:02:44 -0800 (PST) Date: Mon, 07 Dec 2009 14:02:44 -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: <20091207220244.DA1A06C5242@kilo.networkresonance.com> Subject: [TLS] Closing some open comments on 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, 07 Dec 2009 22:01:09 -0000 Hi folks, I've been going through the list discussion on draft-ietf-tls-renegotiation and wanted to try to close on some of the edits people have proposed. 1. Replace "cipher suite" with magic cipher suite value (MCSV) throughout. 2. Add "Updates: RFC 5246, 4366, 4347". Pasi, should we be explicitly stating 4346 and 2246? ISTM we already transitively update them, but I don't care either way. 3. Rewrite the introduction along the lines suggested by Marsh Ray, Nicolas Williams, David-Sarah Hopwood, and others to more accurately capture the entities which are being spliced here. I will propose new text on the list. 4. Channel bindings: replace the end of S 1. with: "The data used in the extension is similar to, but not the same as, the channel binding data used in [I-D.altman-tls-channel-bindings], however this extension is not a generic-purpose RFC 5056 channel binding facility." Nico, did you have other text you wanted? 5. Explicitly state that this extension also applies to DTLS and that the same normativity levels apply. 6. Explicitly state that this extension may also be used with SSLv3 (we don't have any authority to update SSLv3 in any way but we can certainly say that there is no technical obstacle.) 7. Clarify that RI MUST be generated in all rehandshakes, per the issue Martin raised earlier and proposed resolution by Marsh and Nelson. 8. Rewrite the introduction to more clearly elucidate the impact on app-level protocols. As Chris Newman has pointed out it currently apples primarily to HTTPS, but we should have some non-HTTPS text. I will propose new text on the list. 9. Rewrite the section about identity changes in Security Considerations. I'll propose new text on the list. I'll also make whatever small editorial changes I see. If I've missed something important that people think there is consensus on, please let me know. There are a lot of messages, so I may well have. Best, -Ekr From ekr@networkresonance.com Mon Dec 7 14:02: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 69FEE28C0E0 for ; Mon, 7 Dec 2009 14:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.925 X-Spam-Level: X-Spam-Status: No, score=0.925 tagged_above=-999 required=5 tests=[AWL=0.030, 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, 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 MjfLYp0tJKX9 for ; Mon, 7 Dec 2009 14:02:51 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id B4FC53A63EB for ; Mon, 7 Dec 2009 14:02:51 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id E36B16C5243 for ; Mon, 7 Dec 2009 14:04:27 -0800 (PST) Date: Mon, 07 Dec 2009 14:04:27 -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: <20091207220427.E36B16C5243@kilo.networkresonance.com> Subject: [TLS] What is spliced X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 22:02:52 -0000 There has been a bunch of discussion about what the introduction should say about what is spliced together in this attack. Here's my proposed new text, based on trying to integrate various comments from Nelson, Marsh, etc. This attack can be prevented by cryptographically binding renegotiation handshakes to the enclosing TLS channel, or more properly, to the TLS handshake which established the security parameters over which the new handshake is being performed. This prevents the attacker from splicing a negotiation occuring over one set of security parameters (including the initial pre-handshake set of TLS_NULL_WITH_NULL_NULL) into another set of security parameters. An attempt by an attacker to inject himself as described above will result in a mismatch of the extension and can thus be detected. The data used in the extension is similar to, but not the same as, the channel binding data used in [I-D.altman-tls-channel-bindings], however this extension is not a generic-purpose RFC 5056 channel binding facility. Comments? -Ekr From djhopwood@googlemail.com Mon Dec 7 14:18: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 F03143A697D for ; Mon, 7 Dec 2009 14:17:59 -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 K8BNmXBIkYPI for ; Mon, 7 Dec 2009 14:17:55 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 27D343A6782 for ; Mon, 7 Dec 2009 14:17:51 -0800 (PST) Received: by ewy3 with SMTP id 3so68720ewy.13 for ; Mon, 07 Dec 2009 14:17: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=RM/OCYDtAQlIVEs5crsNhRh9KDmPZyjtIbUV1uM01l4=; b=Yv4XFM6V2L67112OSsQB5X6bZBkJNRC0avToJMwONDeV4pH4C93Y3LStfOK0HDSQnM r9iw5tbVo4kYnluRf40Is03mdcxMSY+nVCC5zJHBX2AnukH87cSrVEbnEll0R4B5nl4m +d3k2iP4J0dlenfOKZ/YlY69VJRiNwK5sTFjA= 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=trJB4pkX7L5zzYBHgMSa35jG9luxz/k57YJQVDwT8l3YdANQ8C7JHJtAeFAEN/aMfe MO5oP0mR1KtzqRGl/zYRYQSdBJtO0wdgouEMH6QAhL2MROg+AztTcyGpMon5GKccVQMF tOix8Gb/L0FV7nZdf3VrHB6TNn9Dm2NgHGrfI= Received: by 10.213.96.221 with SMTP id i29mr8525949ebn.96.1260224246458; Mon, 07 Dec 2009 14:17:26 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 10sm9816574eyz.15.2009.12.07.14.17.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 14:17:25 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1D7EFF.1050605@jacaranda.org> Date: Mon, 07 Dec 2009 22:17:35 +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: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> <4B1D70D8.3070108@jacaranda.org> <20091207212656.GK861@Sun.COM> In-Reply-To: <20091207212656.GK861@Sun.COM> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig373735F0906B1AFD75D6C285" Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 22:18:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig373735F0906B1AFD75D6C285 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 09:17:12PM +0000, David-Sarah Hopwood wrote: >> Pasi.Eronen@nokia.com wrote: >>> Well, I think one thing we've learned here is that none of the >>> reasonable-looking definitions of "TLS channel" are exactly what >>> typical TLS libraries offer to applications (via their APIs -- and >>> there's some variation between APIs, too). >> >> I would expect a definition of "TLS channel" to inform the design of >> new APIs or API abstractions. I wouldn't expect it to change existing >> abstractions in current APIs, except possibly those that already have >> an abstraction that almost-but-not-quite corresponds to a TLS channel,= >> and where the change to make it exactly correspond can be done compati= bly. >=20 > Look at draft-altman-tls-channel-bindings. The impact on APIs is reall= y > rather trivial. All APIs will have some sort of handle to a TLS > connection. A connection is almost a channel. From a connection you > need a way to extract the channel bindings. >=20 > Now, the only question is: is a series of connections resulting from > re-negotiations one channel? Or is a channel =3D=3D to a connection? >=20 > (Here I'm using "connection" to mean something that's barely referred b= y > that name in RFC5246, but which is: the state established by a TLS > handshake and the record layer messages exchanged under its protection.= ) I disagree that the abstraction presented by most TLS libraries corresponds to a connection in the above sense. They typically present a handle to a stream that may span multiple connections in that sense. To change this stream-handle to a connection-handle, cannot be done without breaking renegotiation functionality, from the point of view of existing unmodified applications that rely on that functionality. [...] >>> Also, different people seem to have somewhat different expectations >>> what properties such a "channel" should have. For example, if the >>> certificate of peer changes in renegotiation, is that just a differen= t >>> certificate for the same identity, or a different identity? Does the >>> application need to determine which received application_data byte >>> corresponds to which certificate? >> >> The abstraction of "channel" most useful for understanding the attack >> and the authentication properties of TLS, is one such that every >> completed handshake begins a new channel -- whether or not there are >> changes in identity information, and independent of whether the >> handshake is abbreviated or full. >=20 > For understanding the attack, yes. But see below. >=20 >> (I was mistaken in claiming earlier that only full handshakes should >> be considered to start a new channel. Any pair of Finished messages >> creates a new channel identifier, and therefore should be considered >> to create a new channel.) >=20 > Prior to fixing the re-negotiation vulnerability we should have > considered each negotiation as resulting in a separate channel: then > applying channel binding as an analysis tool would have made the MITM > problem instantly apparent. >=20 > Following the fix to the re-negotiation vulnerability I think we should= > say that the first negotiation establishes a channel and that the > subsequent ones do not, just as in SSHv2. In that case any attempt by the application to synchronously retrieve identity information associated with the channel, may be subject to race conditions. It is possible to just document that problem and leave applications to deal with it, but I have little confidence that they will do so correctly. If, OTOH, the channel abstraction is per-handshake, then the application can rely on the identity information remaining constant for a given channel. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig373735F0906B1AFD75D6C285 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/ iF4EAREIAAYFAksdfwYACgkQWUc8YzyzqAcOdgD9E+54KtI/txenXJpgitUTOuD2 iit4iUNi8TGg4CZzO7gA/i0lSmN+aDo/8lW8c7Aa1qiZVOm9HBN+tWjUCnqNufLA =LOMw -----END PGP SIGNATURE----- --------------enig373735F0906B1AFD75D6C285-- From Nicolas.Williams@sun.com Mon Dec 7 14:32: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 A64123A67D8 for ; Mon, 7 Dec 2009 14:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.152, 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 P9CpnQdyKLpm for ; Mon, 7 Dec 2009 14:32: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 C489F3A63EB for ; Mon, 7 Dec 2009 14:32:57 -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 nB7MWlfL003206 for ; Mon, 7 Dec 2009 22:32:47 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 nB7MWl3b050487 for ; Mon, 7 Dec 2009 15:32: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 nB7ML0QW001271; Mon, 7 Dec 2009 16:21:00 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7MKxpR001270; Mon, 7 Dec 2009 16:21:00 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 16:20:58 -0600 From: Nicolas Williams To: David-Sarah Hopwood Message-ID: <20091207222058.GQ861@Sun.COM> References: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> <4B1D70D8.3070108@jacaranda.org> <20091207212656.GK861@Sun.COM> <4B1D7EFF.1050605@jacaranda.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1D7EFF.1050605@jacaranda.org> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 22:32:58 -0000 On Mon, Dec 07, 2009 at 10:17:35PM +0000, David-Sarah Hopwood wrote: > Nicolas Williams wrote: > > (Here I'm using "connection" to mean something that's barely referred by > > that name in RFC5246, but which is: the state established by a TLS > > handshake and the record layer messages exchanged under its protection.) > > I disagree that the abstraction presented by most TLS libraries > corresponds to a connection in the above sense. They typically present > a handle to a stream that may span multiple connections in that sense. > To change this stream-handle to a connection-handle, cannot be done > without breaking renegotiation functionality, from the point of view > of existing unmodified applications that rely on that functionality. Fair enough, but that's good enough, provided that: a) all the individual connections are chained by channel binding via the RI, b) a single one of those connections is identified for providing the channel bindings data for the application. (I.e., the same as SSHv2.) > > Following the fix to the re-negotiation vulnerability I think we should > > say that the first negotiation establishes a channel and that the > > subsequent ones do not, just as in SSHv2. > > In that case any attempt by the application to synchronously retrieve > identity information associated with the channel, may be subject to > race conditions. It is possible to just document that problem and > leave applications to deal with it, but I have little confidence that > they will do so correctly. If, OTOH, the channel abstraction is > per-handshake, then the application can rely on the identity information > remaining constant for a given channel. See above. No race conditions are present if you finger the initial connection as the one to provide the channel bindings data for the application to use. Note that the identity information is only relevant to the tls-server-end-point channel binding type, and then only the server's certificate is relevant. If the initial connection used an anon DH cipher suite then there will be no tls-server-end-point channel bindings data for that channel. ID info is utterly irrelevant to the tls-unique channel binding type. Nico -- From djhopwood@googlemail.com Mon Dec 7 14:47: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 9D27D3A686C for ; Mon, 7 Dec 2009 14:47:04 -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 RssVKt5wc1Oq for ; Mon, 7 Dec 2009 14:47:03 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 1CEBA3A680D for ; Mon, 7 Dec 2009 14:47:02 -0800 (PST) Received: by ewy3 with SMTP id 3so103007ewy.13 for ; Mon, 07 Dec 2009 14:46: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=7JenCRwZEkZqSbpqUXduqTIR/TigNxqn8OkU0meM4yA=; b=uSiOmBQcyD3QCubs3x4TM8RQa/R0b2wXNFAudTG5S0DxGYQl/9ODdEo/YNZkmwXKNU YX6FLh38t1JQlDCA3FVuyc522KI66cclCCdBi6aXelxZdl/G1Plksussk4wfPfhomEZ2 0Ff0xnhHtTgBaZ4NQvApt8Jz+3pLy+FgY3/k0= 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=gO0Pb6r5aixhHDVSN91l4hzrFXDB+U5XPhfFEBBFAT6zRrldDBmHnH/MsqCeDGGJ2e qYlHua1tlOt6+KgcnEatnzfSZ9v+YYgvjzMFiBwY+ApdmnPC+OiLBMKyJWjN4SNl6HmR L+HJJf49fDOh5mpOQTbLEnjD66PKZydeawDPo= Received: by 10.213.50.139 with SMTP id z11mr229078ebf.13.1260226005320; Mon, 07 Dec 2009 14:46:45 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 14sm3679335ewy.7.2009.12.07.14.46.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 14:46:44 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1D85DE.3030608@jacaranda.org> Date: Mon, 07 Dec 2009 22:46:54 +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: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> <20091207163728.GH773@Sun.COM> <4B1D747E.1080001@jacaranda.org> <20091207213712.GM861@Sun.COM> In-Reply-To: <20091207213712.GM861@Sun.COM> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9A7310729097D0EC30C940CD" Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 22:47:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9A7310729097D0EC30C940CD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 09:32:46PM +0000, David-Sarah Hopwood wrote: >> Nicolas Williams wrote: >>> If the re-negotiation bug is fixed then I'd say that re-negotiation d= oes >>> not change the channel (same as in SSHv2, which never had this bug). >>> >>> If the re-negotiation bug is NOT fixed then I'd say that re-negotiati= on >>> does change the channel. >> >> I think this is a misunderstanding of the RFC5056 concept of "channel"= =2E >> Channel binding makes one channel cryptographically dependent on anoth= er; >> it does not identify them. There is an unfortunate English usage ambiguity here: I meant "identify" = in the sense of "make identical" or "equate", not in the sense of "give a na= me to". For "channel binding" I meant the gerund. Later in the post I used "channel identifier" for the noun. [...] >>>> This may have implications on what exactly the channel in RFC5056 >>>> sense would be. Or it may not -- the questions "what kind of >>>> abstraction TLS libraries should provide to applications" and "what >>>> should be 'channel' in RFC5056 sense" are certainly related, but not= >>>> the same. >>> >>> If we wanted to believe that re-negotiation replaces an existing chan= nel >>> with a different one then we wouldn't consider the re-negotiation bug= a >>> bug. >> >> Yes, we would, because: >> >> - the channels are not bound, and they should be (even if they are >> presented to an application as separate streams). >=20 > Following the fix they will be! The fact that they aren't bound *is* > the bug in re-negotiation that we're fixing. Your statement above ("If we wanted to believe...") was about the pre-fix= situation. The fact that the channels will be bound after the fix doesn't imply that= they are the same channel. In particular, they will be treated as differe= nt channels by applications using the 'tls-unique' channel binding type in . --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig9A7310729097D0EC30C940CD 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/ iF4EAREIAAYFAksdheQACgkQWUc8YzyzqAeyhQD/aVttHrpDKiztQMrdXQbtyYnV nVI/LiUOZNLNjakJKfcA/2HRNo5X+ohhVqcEjqUSlQ8qU1Do5uk+Fe3jNgSMF1SU =JhJJ -----END PGP SIGNATURE----- --------------enig9A7310729097D0EC30C940CD-- From Nicolas.Williams@sun.com Mon Dec 7 14:49: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 65C713A680D for ; Mon, 7 Dec 2009 14:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.146, 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 gDMACa9pNEZQ for ; Mon, 7 Dec 2009 14:49: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 C03303A63EB for ; Mon, 7 Dec 2009 14:49:11 -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 nB7Mn1mg009746 for ; Mon, 7 Dec 2009 22:49:01 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 nB7Mn1Xb059677 for ; Mon, 7 Dec 2009 15:49:01 -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 nB7MbE79001384; Mon, 7 Dec 2009 16:37:15 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7MbE4D001383; Mon, 7 Dec 2009 16:37:14 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 16:37:14 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20091207223714.GR861@Sun.COM> References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091207220244.DA1A06C5242@kilo.networkresonance.com> User-Agent: Mutt/1.5.7i Cc: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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, 07 Dec 2009 22:49:41 -0000 On Mon, Dec 07, 2009 at 02:02:44PM -0800, Eric Rescorla wrote: > I've been going through the list discussion on > draft-ietf-tls-renegotiation and wanted to try to close on some of the > edits people have proposed. > > 4. Channel bindings: replace the end of S 1. with: > > "The data used in the extension is similar to, but not the same as, the > channel binding data used in [I-D.altman-tls-channel-bindings], however > this extension is not a generic-purpose RFC 5056 channel binding > facility." > > Nico, did you have other text you wanted? RFC5056 needs to be an actual, informative reference. Also, since we use both Finished messages this resembles the tls-unique-for-telnet CB most: The data used in the extension is similar to, but not the same as, the tls-unique and/or tls-unique-for-telnet channel bindings described in [I-D.altman-tls-channel-bindings], however this extension is not a generic-purpose RFC 5056 [RFC5056] channel binding facility." Nico -- From djhopwood@googlemail.com Mon Dec 7 14:50: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 25D1228C0E5 for ; Mon, 7 Dec 2009 14:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nax-eVUrn2vq for ; Mon, 7 Dec 2009 14:50:45 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 847A43A6810 for ; Mon, 7 Dec 2009 14:50:45 -0800 (PST) Received: by ewy3 with SMTP id 3so107349ewy.13 for ; Mon, 07 Dec 2009 14:50: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=/BN213CdcAOmpbuqZ5Tii7Qb1SgTHusWECKVI4RNJ74=; b=Bc/VFI+DAjj4xR6Yb//uvt5H7EH6839o5zzfGPQrc/fZiORj493uWbFAl3iH50KjF4 xefDllVsev8AZ2tBxJPHB35q5yaWJEQFaQQzQ3fnPw7/7cdHf8aZpNlZwU8F3wGIEPCT SjCz/P/iM4Y/sgHBcfN9a7Zhh1W4WrMVBwVB8= 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=b8zODoAt4dgjKMMxOS5HGs86TVEQ2voRO/dBQAJ1XCKTKjLsJPaYmSNuvGLDIr2xeg b63Bs3idzc2tNcBC+7RQVVyKsR/X7nBnMgycX2aJQI5KPbFn7IpaXeH7E3BMAAR+ljww e8Jms+PPUcylFrYLg9cBh7vMAeKK0H8NfsEo4= Received: by 10.213.57.19 with SMTP id a19mr230927ebh.11.1260226230710; Mon, 07 Dec 2009 14:50:30 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 5sm9785342eyh.24.2009.12.07.14.50.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 14:50:30 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1D86C6.10501@jacaranda.org> Date: Mon, 07 Dec 2009 22:50: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: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp> <4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com> <4B1D70D8.3070108@jacaranda.org> <20091207212656.GK861@Sun.COM> <4B1D7EFF.1050605@jacaranda.org> In-Reply-To: <4B1D7EFF.1050605@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3DD3CE5545192420C82A6254" Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2009 22:50:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3DD3CE5545192420C82A6254 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David-Sarah Hopwood wrote: > Nicolas Williams wrote: >> Following the fix to the re-negotiation vulnerability I think we shoul= d >> say that the first negotiation establishes a channel and that the >> subsequent ones do not, just as in SSHv2. >=20 > In that case any attempt by the application to synchronously retrieve > identity information associated with the channel [abstraction], including the tls-unique channel binding value > may be subject to > race conditions. It is possible to just document that problem and > leave applications to deal with it, but I have little confidence that > they will do so correctly. If, OTOH, the channel abstraction is > per-handshake, then the application can rely on the identity informatio= n > remaining constant for a given channel. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3DD3CE5545192420C82A6254 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/ iF4EAREIAAYFAksdhsYACgkQWUc8YzyzqAcA0wEAgkjliKN+zk5JcXP9zPEJ9ogA oZ9nZ1cUyGhgULdpMA8A/ilwdnvob0kR3fBbn8CN0VEZxVaoVZ7xpkmOVYuoaAQZ =NJlt -----END PGP SIGNATURE----- --------------enig3DD3CE5545192420C82A6254-- From ekr@networkresonance.com Mon Dec 7 14:59: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 134453A68C1 for ; Mon, 7 Dec 2009 14:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[AWL=0.027, 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, 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 6DJTNv7dS7xd for ; Mon, 7 Dec 2009 14:59:24 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 627503A67D8 for ; Mon, 7 Dec 2009 14:59:24 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id BB2226C5249; Mon, 7 Dec 2009 15:00:59 -0800 (PST) Date: Mon, 07 Dec 2009 15:00:59 -0800 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20091207223714.GR861@Sun.COM> References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <20091207223714.GR861@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: <20091207230059.BB2226C5249@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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, 07 Dec 2009 22:59:25 -0000 At Mon, 7 Dec 2009 16:37:14 -0600, Nicolas Williams wrote: > > On Mon, Dec 07, 2009 at 02:02:44PM -0800, Eric Rescorla wrote: > > I've been going through the list discussion on > > draft-ietf-tls-renegotiation and wanted to try to close on some of the > > edits people have proposed. > > > > 4. Channel bindings: replace the end of S 1. with: > > > > "The data used in the extension is similar to, but not the same as, the > > channel binding data used in [I-D.altman-tls-channel-bindings], however > > this extension is not a generic-purpose RFC 5056 channel binding > > facility." > > > > Nico, did you have other text you wanted? > > RFC5056 needs to be an actual, informative reference. Also, since we > use both Finished messages this resembles the tls-unique-for-telnet CB > most: > > The data used in the extension is similar to, but not the same as, > the tls-unique and/or tls-unique-for-telnet channel bindings > described in [I-D.altman-tls-channel-bindings], however this > extension is not a generic-purpose RFC 5056 [RFC5056] channel binding > facility." Sold. -Ekr From mrex@sap.com Mon Dec 7 15:15: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 1255F3A6957 for ; Mon, 7 Dec 2009 15:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 AR9mU-Yvicmi for ; Mon, 7 Dec 2009 15:15: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 8E2813A69CD for ; Mon, 7 Dec 2009 15:15:46 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB7NFYaw003370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Dec 2009 00:15:35 +0100 (MET) From: Martin Rex Message-Id: <200912072315.nB7NFTqS017397@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Tue, 8 Dec 2009 00:15:29 +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: [TLS] OpenSSL 0.9.8l diffs for draft-mrex-tls-secure-renegotiation-03 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, 07 Dec 2009 23:15:48 -0000 Dear TLS, Here is an implementation of draft-mrex-tls-secure-renegotiation-03: ftp://ftp.sap.com/pub/ietf-work/tls/ ftp://ftp.sap.com/pub/ietf-work/tls/OpenSSL-0.9.8l-draft-mrex-tls-secure-renegotiation-03-20091207.diff ftp://ftp.sap.com/pub/ietf-work/tls/OpenSSL-0.9.8l-draft-mrex-tls-secure-renegotiation-03-20091207.zip It is a diff to OpenSSL-0.9.8l. It should work for SSLv2-BC ClientHello, SSLv3 and TLS Implementation notes: - it includes fallback for OpenSSL when compiled without TLS Extensions - It appears to work for DTLS as well, but I admit to have not yet understood how that works exactly. - for enabling renegotiation with old peers, I copied SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION from newer snapshot and removed that bit from SSL_OP_ALL since all OP-Bits are gone, the app must provide different OP-values for Server and Client SSL_CTX in order to distinguish client/server I'm having slight troubles with OpenSSL's "s_client" and "s_server" applications. It appears that there is insufficient return-code chechking for the SSL_renegotiate() calls in several places of OpenSSL. - SSL_renegotiate() might need to reset "new_session" when the called renegotiation method fails (rc=0) - both s_server and s_client call SSL_renegotiate(), but do _not_ check the return codes and write confusing/incorrect messages to the screen (in particular for 0.9.8l where renegotiation has been disabled by default). - Since SSL_do_handshake() seems to always return "1", independent of whether renegotiation is performed or the request rejected, the output of "SSL_do_handshake()=1 by s_server is confusing. -Martin From djhopwood@googlemail.com Mon Dec 7 16:09: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 1753E3A693D for ; Mon, 7 Dec 2009 16:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKGP2DEFQqDv for ; Mon, 7 Dec 2009 16:09:16 -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 239313A6858 for ; Mon, 7 Dec 2009 16:09:15 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so551564eyd.51 for ; Mon, 07 Dec 2009 16:09: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=cNjUSFpCwWszF0/q1fRza96ivQwhDcLlkRJEWLCw3oA=; b=dkB+QoCZEAASX2o+DlE7yHaKsmJBcZPmnekWksAdfFWMwnW/T4v7m3IA7w8lUqp6aa RCdMUnBNWIU7Ol7ivxi5H7pkXoLJPKY7VHJlsEkwP5HbbQ5nWcIXpvu+O3dhyhVbJ87l VaN6kvMOnlf+b9p6N+A1G+PLMHX4aCGPAJzpY= 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=VZhNhU1YOcuU6oohwWfLXVykcMe3Y8F7WO47O8Mw3cseHmhDLg1Qr6ZgxUScpNteyA zW6hBLLVLwq7J8j5uJUYCr+p1hoyT8QBfHIqc1pcJ16wc+Y3zrlrPIzQZDCQ3vYdF8M/ zGzio2oYmNNm059JT8Q6OBH9zhAgN7ny23v/8= Received: by 10.213.0.144 with SMTP id 16mr7828531ebb.37.1260230942404; Mon, 07 Dec 2009 16:09:02 -0800 (PST) Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 14sm3708435ewy.15.2009.12.07.16.09.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 16:09:01 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B1D9928.6090407@jacaranda.org> Date: Tue, 08 Dec 2009 00:09:12 +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: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <20091207223714.GR861@Sun.COM> <20091207230059.BB2226C5249@kilo.networkresonance.com> In-Reply-To: <20091207230059.BB2226C5249@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD42DA560BA3D6D5EFA0C927C" Subject: Re: [TLS] Closing some open comments on 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, 08 Dec 2009 00:09:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD42DA560BA3D6D5EFA0C927C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > At Mon, 7 Dec 2009 16:37:14 -0600, > Nicolas Williams wrote: >> RFC5056 needs to be an actual, informative reference. Also, since we >> use both Finished messages this resembles the tls-unique-for-telnet CB= >> most: >> >> The data used in the extension is similar to, but not the same as, >> the tls-unique and/or tls-unique-for-telnet channel bindings the data used in the tls-unique and/or tls-unique-for-telnet channel bind= ing types >> described in [I-D.altman-tls-channel-bindings], however this >> extension is not a generic-purpose RFC 5056 [RFC5056] channel bindi= ng generic-purpose -> general-purpose >> facility." > =20 > Sold. +1. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigD42DA560BA3D6D5EFA0C927C 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/ iF4EAREIAAYFAksdmS4ACgkQWUc8YzyzqAcEaAD+NQqQtMvETA3NZ4BaizaQV+p3 jYCfVOqFtqs9T+c75C4A/j5n2tm/TfW9hjM7jfN4+X+PpqmDOc7EedQ0+FwGgh9M =hWC2 -----END PGP SIGNATURE----- --------------enigD42DA560BA3D6D5EFA0C927C-- From mrex@sap.com Mon Dec 7 17:05: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 DE83628C1A6; Mon, 7 Dec 2009 17:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 pnR40v7hTGyv; Mon, 7 Dec 2009 17:05:22 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F399528C18F; Mon, 7 Dec 2009 17:05:21 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB8159L2018394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 02:05:10 +0100 (MET) From: Martin Rex Message-Id: <200912080105.nB8158co024213@fs4113.wdf.sap.corp> To: Chris.Newman@Sun.COM (Chris Newman) Date: Tue, 8 Dec 2009 02:05:08 +0100 (MET) In-Reply-To: from "Chris Newman" at Dec 1, 9 11:04: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: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 08 Dec 2009 01:05:24 -0000 Chris Newman wrote: > > Evaluation relative to draft-mrex-tls-secure-renegotiation-03: > > Kudos to Martin Rex for producing such a good alternate proposal. The > introductory text up to and including section 4.1 is very good and would > improve draft-ietf-tls-renegotiation. While I would support a consensus to > publish the mrex document as the solution, I presently prefer > draft-ietf-tls-renegotiation-01 for four reasons: > > 1. Running code: multiple implementations and interop testing was performed > on an earlier version of draft-ietf-tls-renegotiation. I have published a diff for OpenSSL-0.9.8l that implements draft-mrex-tls-secure-renegotiation-03.txt. ftp://ftp.sap.com/pub/ietf-work/tls/ It amounts to ~120 Lines-of-Code (180 if you include empty lines and braces). It is less than half the code footprint of the TLS extension RI that is contained in openssl-0.9.8-stable-SNAP-20091205, (and that TLS extension RI implementation is based on an earlier proposal, doesn't have the MCSV yet, so lacks support for SSLv3 SSLv2 ClientHellos, conservative clients and reconnect fallbacks and protection from downgrade attacks.) So if you're in a hurry, here is a document in better shape, an implementation in better shape, which requires less code changes -- in particular for old implementations that do not contain TLS extensions (how to implement S->C signaling with no TLS extensions coding is part of my patch for OpenSSL and ~20 LoC). As has been previously discussed, there are very few code paths and a failSAFE design, so this approach is _much_ easier to test than TLS extension RI. > 2. Impact to core protocol handshake: The mrex proposal alters the > handshake to include data that is not exchanged in-protocol. My proposal does not "alter" the handshake. It just defines extra handshake messages that are _NOT_ transferred over the network (since both peers already have it, there is no need to acutally send them). > The point being the mrex proposal requires more analysis > to verify impact. As we're in a hurry, I prefer to easier to analyze > proposal. I don't see a need for further analysis. I put more thought on this one now than I put into finding the TLS renegotiation vulnerability, so by now I pretty sure it is as sound, safe and secure as the rest of the TLS handshake design. There are _no_ new concepts. > 3. Extensibility. In my experience one of the protocol design features > most important to get right is extensibility. SSL/TLS didn't really > get that right until v1.2 (which is causing problems now). > As draft-ietf-tls-renegotiation uses the TLS extension > facility more extensively, it will help future-proof more > implementations. It doesn't simply "use", draft-ietf-tls-renegotiation will _require_ it back to 1995 and be quite hostile about interop with the installed base If you want an example for "use" of TLS extension in a non-offending fashion, draft-mrex-tls-secure-renegotiation-03 "uses" TLS extensions. > 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST > in some circumstances. That approach is untested in the field This claim is quite unsubstantiated. My proposal requires TLS_RENEGO_PROTECTION_REQUEST, but adding new ciphersuites is something that has been done many times before quite successfully. The AES ciphersuites (rfc3268,June 2002) came before TLS extensions and didn't remotely cause any of the interop problems which TLS extensions were found to cause. Today, Firefox 3.0 will send Camellia ciphersuites in a SSLv2 ClientHello. There is fairly broad consensus in the TLS WG that the extensibility of the cipher_suites field in ClientHello has by far the least number of interop problems in the TLS protocol. Severe interop problems are known for TLS protocol versions and presence of TLS extensions. > > * There may not be a sufficient number of "extension intolerant" SSL/TLS > servers in operation to justify the added complexity of > TLS_RENEGO_PROTECTION_REQUEST. However, I do not object to inclusion as > it's possibly helpful for some alleged extension intolerant servers > compliant with early drafts of SSLv3 and it helped move closer to WG > consensus. The Complexity of TLS_RENEGO_PROTECTION_REQUEST is a magnitude smaller than that of a TLS extension RI in the initial ClientHello (and in renegotiation ClientHellos during backwards interop with old servers). You can see from the OpenSSL diff I provided above, just how much smaller and easier to implement the MCSV is compared to TLS extension RI. > > * Non-extension signaling for ServerHello: I am strongly opposed to using > any mechanism other than TLS extensions for signaling in the ServerHello. > I found all such proposals (including overloading the version field) far > too risky. As the earlier mrex draft proposing such mechanisms was > replaced by a revision which now uses the extension mechanism, I believe > the matter is settled. Thanks. I said from the beginning that I'm open to suggestions for the Server->Client signaling. And I adopted the solution from draft-ietf-tls-renegotiation-01.txt after it had been added there. -Martin From Pasi.Eronen@nokia.com Tue Dec 8 00:50: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 913943A6958 for ; Tue, 8 Dec 2009 00:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 m4aLmg8Usutm for ; Tue, 8 Dec 2009 00:50:51 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AD6413A67AA for ; Tue, 8 Dec 2009 00:50:51 -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 nB88oGXl020448; Tue, 8 Dec 2009 02:50:40 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 10:50:39 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 10:50:35 +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); Tue, 8 Dec 2009 10:50:30 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 8 Dec 2009 09:50:29 +0100 From: To: Date: Tue, 8 Dec 2009 09:50:27 +0100 Thread-Topic: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Thread-Index: AcpzWpmEvzMooeMeRPu9gUUtWIuJ2wEiHhfQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31A4FCB4@NOK-EUMSG-01.mgdnok.nokia.com> References: from "Chris Newman" at Dec 1, 9 11:04:43 pm <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> In-Reply-To: <200912021419.nB2EJr13019589@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: 08 Dec 2009 08:50:30.0190 (UTC) FILETIME=[7EC98CE0:01CA77E3] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 08:50:52 -0000 Martin Rex wrote: > Chris Newman wrote: >=20 > > 1. Running code: multiple implementations and interop testing was > > performed on an earlier version of draft-ietf-tls-renegotiation. >=20 > Even EKR admitted that implementing the update is an insignificant > amount of work. Martin: Do you agree with EKR here or not? (I guess "the update" here means "any of the proposed variants"). Best regards, Pasi From Pasi.Eronen@nokia.com Tue Dec 8 01:05: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 3644E28C0FF for ; Tue, 8 Dec 2009 01:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 ty0ZhJCdl-4f for ; Tue, 8 Dec 2009 01:05:37 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BC9DE28C0FD for ; Tue, 8 Dec 2009 01:05:34 -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 nB894rgw008030; Tue, 8 Dec 2009 11:05:21 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 11:04:38 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 11:04:33 +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); Tue, 8 Dec 2009 11:04:28 +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; Tue, 8 Dec 2009 10:04:27 +0100 From: To: , Date: Tue, 8 Dec 2009 10:04:27 +0100 Thread-Topic: [TLS] Closing some open comments on draft-ietf-tls-renegotiation Thread-Index: Acp3iMjO5VoiIH1MSEe4SPY4uEN82wAXGhkA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31A4FCF1@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> In-Reply-To: <20091207220244.DA1A06C5242@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: 08 Dec 2009 09:04:29.0107 (UTC) FILETIME=[72D22030:01CA77E5] X-Nokia-AV: Clean Subject: Re: [TLS] Closing some open comments on 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, 08 Dec 2009 09:05:38 -0000 Eric Rescorla wrote: > 2. Add "Updates: RFC 5246, 4366, 4347". Pasi, should we be explicitly > stating 4346 and 2246? ISTM we already transitively update them, but=20 > I don't care either way. Yes, we should -- since this document is fixing an important bug=20 in 2246/4346, we want "Updated by RFCNNNN" to appear in the RFC=20 index for 2246/4346, too. Best regards, Pasi From Pasi.Eronen@nokia.com Tue Dec 8 01:14: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 824D93A6995 for ; Tue, 8 Dec 2009 01:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 046JKfwri5DY for ; Tue, 8 Dec 2009 01:14:15 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D4CC33A67AA for ; Tue, 8 Dec 2009 01:14: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 nB89DiTp011107 for ; Tue, 8 Dec 2009 11:14:01 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 11:13:34 +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); Tue, 8 Dec 2009 11:13:29 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 8 Dec 2009 10:13:22 +0100 From: To: Date: Tue, 8 Dec 2009 10:13:20 +0100 Thread-Topic: Summarizing identity change discussion so far Thread-Index: Acp35q+5MB/IK2o8TM+TSRCqs64JxA== Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@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: 08 Dec 2009 09:13:29.0852 (UTC) FILETIME=[B52143C0:01CA77E6] X-Nokia-AV: Clean Subject: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 09:14:16 -0000 (wearing Area Director hat) Although the IETF Last Call is still underway, here's a short attempt to summarize the discussion regarding identity changes (Section 7) so far: - We seem to agree that changing the certificate/identity=20 during secure renegotiation (so there's no man-in-the-middle, just two parties) could confuse some applications. James Manger's email provides=20 IMHO a good example of what that confusion could be (in this particular=20 example, the confusion has security implications, too): http://www.ietf.org/mail-archive/web/tls/current/msg05122.html - We mostly seem to agree that some applications could not just handle certificate/identity changes correctly, but would actually benefit from them.=20 - We seem to agree that it would be a reasonable idea for the TLS library to offer the applications an option where the TLS library checks that the certificate doesn't change during renegotiation.=20 This is an *option* -- an application could decide not to use it,=20 and e.g. do more complex comparisons. - We have much less support for requiring that every TLS library=20 MUST implement this functionality and/or MUST enable it by default (whatever "by default" means in your API), at least in this draft. Unless I'm badly misreading the situation, or it significantly changes during the rest of the IETF Last Call, my proposal here would be as follows: - We do NOT require (with "MUST") any changes to TLS libraries in this regard. - We describe the situation a bit more clearly than the current text does (it seems many people found the current text somewhat unclear). - We recommend that TLS libraries SHOULD provide identity matching (with memcmp, abort handshake if changed) functionality to applications, and SHOULD allow applications to enable/disable this functionality. - We include a sentence or two describing the pros and cons of enabling/not enabling this feature by default, but don't require or recommend any particular default value. - The text probably needs to note that if the applications wants to deal with identity changes, it may need to consider the "which application_data byte(s) correspond to which identity" question (or it may not -- the answer may depend a lot on the application protocol). Does this sound like a reasonable approach? Best regards, Pasi From lists@drh-consultancy.demon.co.uk Tue Dec 8 04:48: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 2BB6A3A685B for ; Tue, 8 Dec 2009 04:48:09 -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 QNHesEa1QEec for ; Tue, 8 Dec 2009 04:48: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 521843A69EE for ; Tue, 8 Dec 2009 04:48:07 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50108 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 1NHzTt-0003p5-10 (return-path ); Tue, 08 Dec 2009 12:47:53 +0000 Message-ID: <4B1E4AFA.7060600@drh-consultancy.demon.co.uk> Date: Tue, 08 Dec 2009 12:47:54 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> In-Reply-To: <20091207220244.DA1A06C5242@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] Closing some open comments on 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, 08 Dec 2009 12:48:09 -0000 Eric Rescorla wrote: > > I'll also make whatever small editorial changes I see. > If I've missed something important that people think there is > consensus on, please let me know. There are a lot of messages, > so I may well have. > In 6.1: If clients wish to ensure that such attacks are impossible, they MUST terminate the connection immediately upon failure to receive the extension without completing the handshake. Should we be more specific about what "terminate the connection" means? Does that mean drop the connection immediately without sending anything else or by sending a fatal alert? If a fatal alert which one? Presumably handshake_failure? I'm thinking here in terms of sending something useful which would most likely appear in server logs to help diagnose the cause: i.e. unpatched server which strict clients refuse to connect to. 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 Tue Dec 8 05:00: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 15EF53A69A5 for ; Tue, 8 Dec 2009 05:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 rU1ZWSF6tDpO for ; Tue, 8 Dec 2009 05:00:42 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id D7C0D3A6992 for ; Tue, 8 Dec 2009 05:00:41 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nB8D0R27021227 for ; Tue, 8 Dec 2009 08:00:27 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAsZaO3r; Tue Dec 8 07:43:39 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Tue, 8 Dec 2009 07:43:38 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Tue, 8 Dec 2009 07:43:38 -0500 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp35q+5MB/IK2o8TM+TSRCqs64JxAAHWCJs Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F97@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 13:00:43 -0000 SU1ITyAtIFllcy4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiB0bHMt Ym91bmNlc0BpZXRmLm9yZyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogdGxzQGlldGYub3Jn IDx0bHNAaWV0Zi5vcmc+DQpTZW50OiBUdWUgRGVjIDA4IDA0OjEzOjIwIDIwMDkKU3ViamVjdDog W1RMU10gU3VtbWFyaXppbmcgaWRlbnRpdHkgY2hhbmdlIGRpc2N1c3Npb24gc28gZmFyDQoNCih3 ZWFyaW5nIEFyZWEgRGlyZWN0b3IgaGF0KQ0KDQpBbHRob3VnaCB0aGUgSUVURiBMYXN0IENhbGwg aXMgc3RpbGwgdW5kZXJ3YXksIGhlcmUncyBhIHNob3J0IGF0dGVtcHQNCnRvIHN1bW1hcml6ZSB0 aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgaWRlbnRpdHkgY2hhbmdlcyAoU2VjdGlvbiA3KSBzbw0K ZmFyOg0KDQotIFdlIHNlZW0gdG8gYWdyZWUgdGhhdCBjaGFuZ2luZyB0aGUgY2VydGlmaWNhdGUv aWRlbnRpdHkgDQpkdXJpbmcgc2VjdXJlIHJlbmVnb3RpYXRpb24gKHNvIHRoZXJlJ3Mgbm8gbWFu LWluLXRoZS1taWRkbGUsIGp1c3QgdHdvDQpwYXJ0aWVzKSBjb3VsZCBjb25mdXNlIHNvbWUgYXBw bGljYXRpb25zLiAgSmFtZXMgTWFuZ2VyJ3MgZW1haWwgcHJvdmlkZXMgDQpJTUhPIGEgZ29vZCBl eGFtcGxlIG9mIHdoYXQgdGhhdCBjb25mdXNpb24gY291bGQgYmUgKGluIHRoaXMgcGFydGljdWxh ciANCmV4YW1wbGUsIHRoZSBjb25mdXNpb24gaGFzIHNlY3VyaXR5IGltcGxpY2F0aW9ucywgdG9v KToNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21z ZzA1MTIyLmh0bWwNCg0KLSBXZSBtb3N0bHkgc2VlbSB0byBhZ3JlZSB0aGF0IHNvbWUgYXBwbGlj YXRpb25zIGNvdWxkIG5vdCBqdXN0IGhhbmRsZQ0KY2VydGlmaWNhdGUvaWRlbnRpdHkgY2hhbmdl cyBjb3JyZWN0bHksIGJ1dCB3b3VsZCBhY3R1YWxseSBiZW5lZml0DQpmcm9tIHRoZW0uIA0KDQot IFdlIHNlZW0gdG8gYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUgaWRlYSBmb3Ig dGhlIFRMUw0KbGlicmFyeSB0byBvZmZlciB0aGUgYXBwbGljYXRpb25zIGFuIG9wdGlvbiB3aGVy ZSB0aGUgVExTIGxpYnJhcnkNCmNoZWNrcyB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBkb2Vzbid0IGNo YW5nZSBkdXJpbmcgcmVuZWdvdGlhdGlvbi4gDQpUaGlzIGlzIGFuICpvcHRpb24qIC0tIGFuIGFw cGxpY2F0aW9uIGNvdWxkIGRlY2lkZSBub3QgdG8gdXNlIGl0LCANCmFuZCBlLmcuIGRvIG1vcmUg Y29tcGxleCBjb21wYXJpc29ucy4NCg0KLSBXZSBoYXZlIG11Y2ggbGVzcyBzdXBwb3J0IGZvciBy ZXF1aXJpbmcgdGhhdCBldmVyeSBUTFMgbGlicmFyeSANCk1VU1QgaW1wbGVtZW50IHRoaXMgZnVu Y3Rpb25hbGl0eSBhbmQvb3IgTVVTVCBlbmFibGUgaXQgYnkgZGVmYXVsdA0KKHdoYXRldmVyICJi eSBkZWZhdWx0IiBtZWFucyBpbiB5b3VyIEFQSSksIGF0IGxlYXN0IGluIHRoaXMgZHJhZnQuDQoN ClVubGVzcyBJJ20gYmFkbHkgbWlzcmVhZGluZyB0aGUgc2l0dWF0aW9uLCBvciBpdCBzaWduaWZp Y2FudGx5IGNoYW5nZXMNCmR1cmluZyB0aGUgcmVzdCBvZiB0aGUgSUVURiBMYXN0IENhbGwsIG15 IHByb3Bvc2FsIGhlcmUgd291bGQgYmUgYXMNCmZvbGxvd3M6DQoNCi0gV2UgZG8gTk9UIHJlcXVp cmUgKHdpdGggIk1VU1QiKSBhbnkgY2hhbmdlcyB0byBUTFMgbGlicmFyaWVzIGluIHRoaXMNCnJl Z2FyZC4NCg0KLSBXZSBkZXNjcmliZSB0aGUgc2l0dWF0aW9uIGEgYml0IG1vcmUgY2xlYXJseSB0 aGFuIHRoZSBjdXJyZW50IHRleHQNCmRvZXMgKGl0IHNlZW1zIG1hbnkgcGVvcGxlIGZvdW5kIHRo ZSBjdXJyZW50IHRleHQgc29tZXdoYXQgdW5jbGVhcikuDQoNCi0gV2UgcmVjb21tZW5kIHRoYXQg VExTIGxpYnJhcmllcyBTSE9VTEQgcHJvdmlkZSBpZGVudGl0eSBtYXRjaGluZw0KKHdpdGggbWVt Y21wLCBhYm9ydCBoYW5kc2hha2UgaWYgY2hhbmdlZCkgZnVuY3Rpb25hbGl0eSB0bw0KYXBwbGlj YXRpb25zLCBhbmQgU0hPVUxEIGFsbG93IGFwcGxpY2F0aW9ucyB0byBlbmFibGUvZGlzYWJsZSB0 aGlzDQpmdW5jdGlvbmFsaXR5Lg0KDQotIFdlIGluY2x1ZGUgYSBzZW50ZW5jZSBvciB0d28gZGVz Y3JpYmluZyB0aGUgcHJvcyBhbmQgY29ucyBvZg0KZW5hYmxpbmcvbm90IGVuYWJsaW5nIHRoaXMg ZmVhdHVyZSBieSBkZWZhdWx0LCBidXQgZG9uJ3QgcmVxdWlyZSBvcg0KcmVjb21tZW5kIGFueSBw YXJ0aWN1bGFyIGRlZmF1bHQgdmFsdWUuDQoNCi0gVGhlIHRleHQgcHJvYmFibHkgbmVlZHMgdG8g bm90ZSB0aGF0IGlmIHRoZSBhcHBsaWNhdGlvbnMgd2FudHMgdG8NCmRlYWwgd2l0aCBpZGVudGl0 eSBjaGFuZ2VzLCBpdCBtYXkgbmVlZCB0byBjb25zaWRlciB0aGUgIndoaWNoDQphcHBsaWNhdGlv bl9kYXRhIGJ5dGUocykgY29ycmVzcG9uZCB0byB3aGljaCBpZGVudGl0eSIgcXVlc3Rpb24gKG9y IGl0DQptYXkgbm90IC0tIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBhIGxvdCBvbiB0aGUgYXBwbGlj YXRpb24gcHJvdG9jb2wpLg0KDQpEb2VzIHRoaXMgc291bmQgbGlrZSBhIHJlYXNvbmFibGUgYXBw cm9hY2g/DQoNCkJlc3QgcmVnYXJkcywNClBhc2kNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From stephen.farrell@cs.tcd.ie Tue Dec 8 05:01: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 13CD43A69F6 for ; Tue, 8 Dec 2009 05:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 mTcISFSYAfFx for ; Tue, 8 Dec 2009 05:01:11 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 25FC53A6992 for ; Tue, 8 Dec 2009 05:01:11 -0800 (PST) Received: from mail156-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 8.1.340.0; Tue, 8 Dec 2009 13:01:00 +0000 Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2-R.bigfish.com (Postfix) with ESMTP id 5EC757A8483; Tue, 8 Dec 2009 13:01:00 +0000 (UTC) X-SpamScore: -41 X-BigFish: VPS-41(zz1418M1432R98dNzz1202hzz1033ILz2dh6bh87h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2 (MessageSwitch) id 1260277259826241_19176; Tue, 8 Dec 2009 13:00:59 +0000 (UTC) Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.252]) by mail156-tx2.bigfish.com (Postfix) with ESMTP id BC7421508057; Tue, 8 Dec 2009 13:00:59 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server id 14.0.482.32; Tue, 8 Dec 2009 13:00:57 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 7675D68002; Tue, 8 Dec 2009 13:00:57 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A004D472A6B; Tue, 08 Dec 2009 13:00:57 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 501C068002; Tue, 8 Dec 2009 13:00:57 +0000 (GMT) Message-ID: <4B1E4E10.90201@cs.tcd.ie> Date: Tue, 8 Dec 2009 13:01:04 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A104D472A6B 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.115.3) X-Reverse-DNS: imx2.tcd.ie Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 13:01:12 -0000 Hi Pasi, I think that all sounds ok, except I don't see any mention in your summary of the fact that a bunch of people (incl. me) said that this just shouldn't be part of the re-negotiation fix. Maybe some of those have changed their minds as a result of the discussion though, I've not checked. If the consensus ends up being to include some text about this, then your approach below sounds ok to me, (though I'd be a bit worried it might take a while to get the right text), but I'd still rather leave it out entirely and have some other document address the identity-change issue in a more considered manner. S. Pasi.Eronen@nokia.com wrote: > (wearing Area Director hat) > > Although the IETF Last Call is still underway, here's a short attempt > to summarize the discussion regarding identity changes (Section 7) so > far: > > - We seem to agree that changing the certificate/identity > during secure renegotiation (so there's no man-in-the-middle, just two > parties) could confuse some applications. James Manger's email provides > IMHO a good example of what that confusion could be (in this particular > example, the confusion has security implications, too): > > http://www.ietf.org/mail-archive/web/tls/current/msg05122.html > > - We mostly seem to agree that some applications could not just handle > certificate/identity changes correctly, but would actually benefit > from them. > > - We seem to agree that it would be a reasonable idea for the TLS > library to offer the applications an option where the TLS library > checks that the certificate doesn't change during renegotiation. > This is an *option* -- an application could decide not to use it, > and e.g. do more complex comparisons. > > - We have much less support for requiring that every TLS library > MUST implement this functionality and/or MUST enable it by default > (whatever "by default" means in your API), at least in this draft. > > Unless I'm badly misreading the situation, or it significantly changes > during the rest of the IETF Last Call, my proposal here would be as > follows: > > - We do NOT require (with "MUST") any changes to TLS libraries in this > regard. > > - We describe the situation a bit more clearly than the current text > does (it seems many people found the current text somewhat unclear). > > - We recommend that TLS libraries SHOULD provide identity matching > (with memcmp, abort handshake if changed) functionality to > applications, and SHOULD allow applications to enable/disable this > functionality. > > - We include a sentence or two describing the pros and cons of > enabling/not enabling this feature by default, but don't require or > recommend any particular default value. > > - The text probably needs to note that if the applications wants to > deal with identity changes, it may need to consider the "which > application_data byte(s) correspond to which identity" question (or it > may not -- the answer may depend a lot on the application protocol). > > Does this sound like a reasonable approach? > > Best regards, > Pasi > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From uri@ll.mit.edu Tue Dec 8 05:02: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 44D483A6992 for ; Tue, 8 Dec 2009 05:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 bWVczI-Q4Wc2 for ; Tue, 8 Dec 2009 05:02:48 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id F02583A685E for ; Tue, 8 Dec 2009 05:02:47 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nB8D2aji024551 for ; Tue, 8 Dec 2009 08:02:36 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAsZaO3r; Tue Dec 8 07:43:39 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Tue, 8 Dec 2009 07:43:38 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Tue, 8 Dec 2009 07:43:38 -0500 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp35q+5MB/IK2o8TM+TSRCqs64JxAAHWCJs Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE853F97@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 13:02:48 -0000 SU1ITyAtIFllcy4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiB0bHMt Ym91bmNlc0BpZXRmLm9yZyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogdGxzQGlldGYub3Jn IDx0bHNAaWV0Zi5vcmc+DQpTZW50OiBUdWUgRGVjIDA4IDA0OjEzOjIwIDIwMDkKU3ViamVjdDog W1RMU10gU3VtbWFyaXppbmcgaWRlbnRpdHkgY2hhbmdlIGRpc2N1c3Npb24gc28gZmFyDQoNCih3 ZWFyaW5nIEFyZWEgRGlyZWN0b3IgaGF0KQ0KDQpBbHRob3VnaCB0aGUgSUVURiBMYXN0IENhbGwg aXMgc3RpbGwgdW5kZXJ3YXksIGhlcmUncyBhIHNob3J0IGF0dGVtcHQNCnRvIHN1bW1hcml6ZSB0 aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgaWRlbnRpdHkgY2hhbmdlcyAoU2VjdGlvbiA3KSBzbw0K ZmFyOg0KDQotIFdlIHNlZW0gdG8gYWdyZWUgdGhhdCBjaGFuZ2luZyB0aGUgY2VydGlmaWNhdGUv aWRlbnRpdHkgDQpkdXJpbmcgc2VjdXJlIHJlbmVnb3RpYXRpb24gKHNvIHRoZXJlJ3Mgbm8gbWFu LWluLXRoZS1taWRkbGUsIGp1c3QgdHdvDQpwYXJ0aWVzKSBjb3VsZCBjb25mdXNlIHNvbWUgYXBw bGljYXRpb25zLiAgSmFtZXMgTWFuZ2VyJ3MgZW1haWwgcHJvdmlkZXMgDQpJTUhPIGEgZ29vZCBl eGFtcGxlIG9mIHdoYXQgdGhhdCBjb25mdXNpb24gY291bGQgYmUgKGluIHRoaXMgcGFydGljdWxh ciANCmV4YW1wbGUsIHRoZSBjb25mdXNpb24gaGFzIHNlY3VyaXR5IGltcGxpY2F0aW9ucywgdG9v KToNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21z ZzA1MTIyLmh0bWwNCg0KLSBXZSBtb3N0bHkgc2VlbSB0byBhZ3JlZSB0aGF0IHNvbWUgYXBwbGlj YXRpb25zIGNvdWxkIG5vdCBqdXN0IGhhbmRsZQ0KY2VydGlmaWNhdGUvaWRlbnRpdHkgY2hhbmdl cyBjb3JyZWN0bHksIGJ1dCB3b3VsZCBhY3R1YWxseSBiZW5lZml0DQpmcm9tIHRoZW0uIA0KDQot IFdlIHNlZW0gdG8gYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUgaWRlYSBmb3Ig dGhlIFRMUw0KbGlicmFyeSB0byBvZmZlciB0aGUgYXBwbGljYXRpb25zIGFuIG9wdGlvbiB3aGVy ZSB0aGUgVExTIGxpYnJhcnkNCmNoZWNrcyB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBkb2Vzbid0IGNo YW5nZSBkdXJpbmcgcmVuZWdvdGlhdGlvbi4gDQpUaGlzIGlzIGFuICpvcHRpb24qIC0tIGFuIGFw cGxpY2F0aW9uIGNvdWxkIGRlY2lkZSBub3QgdG8gdXNlIGl0LCANCmFuZCBlLmcuIGRvIG1vcmUg Y29tcGxleCBjb21wYXJpc29ucy4NCg0KLSBXZSBoYXZlIG11Y2ggbGVzcyBzdXBwb3J0IGZvciBy ZXF1aXJpbmcgdGhhdCBldmVyeSBUTFMgbGlicmFyeSANCk1VU1QgaW1wbGVtZW50IHRoaXMgZnVu Y3Rpb25hbGl0eSBhbmQvb3IgTVVTVCBlbmFibGUgaXQgYnkgZGVmYXVsdA0KKHdoYXRldmVyICJi eSBkZWZhdWx0IiBtZWFucyBpbiB5b3VyIEFQSSksIGF0IGxlYXN0IGluIHRoaXMgZHJhZnQuDQoN ClVubGVzcyBJJ20gYmFkbHkgbWlzcmVhZGluZyB0aGUgc2l0dWF0aW9uLCBvciBpdCBzaWduaWZp Y2FudGx5IGNoYW5nZXMNCmR1cmluZyB0aGUgcmVzdCBvZiB0aGUgSUVURiBMYXN0IENhbGwsIG15 IHByb3Bvc2FsIGhlcmUgd291bGQgYmUgYXMNCmZvbGxvd3M6DQoNCi0gV2UgZG8gTk9UIHJlcXVp cmUgKHdpdGggIk1VU1QiKSBhbnkgY2hhbmdlcyB0byBUTFMgbGlicmFyaWVzIGluIHRoaXMNCnJl Z2FyZC4NCg0KLSBXZSBkZXNjcmliZSB0aGUgc2l0dWF0aW9uIGEgYml0IG1vcmUgY2xlYXJseSB0 aGFuIHRoZSBjdXJyZW50IHRleHQNCmRvZXMgKGl0IHNlZW1zIG1hbnkgcGVvcGxlIGZvdW5kIHRo ZSBjdXJyZW50IHRleHQgc29tZXdoYXQgdW5jbGVhcikuDQoNCi0gV2UgcmVjb21tZW5kIHRoYXQg VExTIGxpYnJhcmllcyBTSE9VTEQgcHJvdmlkZSBpZGVudGl0eSBtYXRjaGluZw0KKHdpdGggbWVt Y21wLCBhYm9ydCBoYW5kc2hha2UgaWYgY2hhbmdlZCkgZnVuY3Rpb25hbGl0eSB0bw0KYXBwbGlj YXRpb25zLCBhbmQgU0hPVUxEIGFsbG93IGFwcGxpY2F0aW9ucyB0byBlbmFibGUvZGlzYWJsZSB0 aGlzDQpmdW5jdGlvbmFsaXR5Lg0KDQotIFdlIGluY2x1ZGUgYSBzZW50ZW5jZSBvciB0d28gZGVz Y3JpYmluZyB0aGUgcHJvcyBhbmQgY29ucyBvZg0KZW5hYmxpbmcvbm90IGVuYWJsaW5nIHRoaXMg ZmVhdHVyZSBieSBkZWZhdWx0LCBidXQgZG9uJ3QgcmVxdWlyZSBvcg0KcmVjb21tZW5kIGFueSBw YXJ0aWN1bGFyIGRlZmF1bHQgdmFsdWUuDQoNCi0gVGhlIHRleHQgcHJvYmFibHkgbmVlZHMgdG8g bm90ZSB0aGF0IGlmIHRoZSBhcHBsaWNhdGlvbnMgd2FudHMgdG8NCmRlYWwgd2l0aCBpZGVudGl0 eSBjaGFuZ2VzLCBpdCBtYXkgbmVlZCB0byBjb25zaWRlciB0aGUgIndoaWNoDQphcHBsaWNhdGlv bl9kYXRhIGJ5dGUocykgY29ycmVzcG9uZCB0byB3aGljaCBpZGVudGl0eSIgcXVlc3Rpb24gKG9y IGl0DQptYXkgbm90IC0tIHRoZSBhbnN3ZXIgbWF5IGRlcGVuZCBhIGxvdCBvbiB0aGUgYXBwbGlj YXRpb24gcHJvdG9jb2wpLg0KDQpEb2VzIHRoaXMgc291bmQgbGlrZSBhIHJlYXNvbmFibGUgYXBw cm9hY2g/DQoNCkJlc3QgcmVnYXJkcywNClBhc2kNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From Pasi.Eronen@nokia.com Tue Dec 8 05:12: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 4FED13A6A0D for ; Tue, 8 Dec 2009 05:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 l476TDyKRvoc for ; Tue, 8 Dec 2009 05:12:44 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 953953A69BB for ; Tue, 8 Dec 2009 05:12:44 -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 nB8DCFUN027663; Tue, 8 Dec 2009 07:12:26 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 15:12:19 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 15:12:14 +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); Tue, 8 Dec 2009 15:12:10 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 8 Dec 2009 14:12:08 +0100 From: To: Date: Tue, 8 Dec 2009 14:12:07 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp4BoPJVyVgAyqSSPeFPl2hJhz35gAACQzw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@cs.tcd.ie> In-Reply-To: <4B1E4E10.90201@cs.tcd.ie> 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: 08 Dec 2009 13:12:10.0043 (UTC) FILETIME=[0CA100B0:01CA7808] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 13:12:47 -0000 The security considerations section of this draft has to describe the fact that even with this fix, renegotiation does things that will surprise application developers, and can cause security vulnerabilities for some of them. That part we cannot avoid -- some text has to be included. It's not absolutely required that the text makes recommendations how to avoid those vulnerabilities, but IMHO it would be a bit strange to just describe the security problem without saying anything how to avoid it... Best regards, Pasi > -----Original Message----- > From: ext Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: 08 December, 2009 15:01 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: tls@ietf.org > Subject: Re: [TLS] Summarizing identity change discussion so far >=20 >=20 > Hi Pasi, >=20 > I think that all sounds ok, except I don't see any mention > in your summary of the fact that a bunch of people (incl. me) > said that this just shouldn't be part of the re-negotiation > fix. Maybe some of those have changed their minds as a result > of the discussion though, I've not checked. >=20 > If the consensus ends up being to include some text about > this, then your approach below sounds ok to me, (though > I'd be a bit worried it might take a while to get the > right text), but I'd still rather leave it out entirely > and have some other document address the identity-change > issue in a more considered manner. >=20 > S. >=20 > Pasi.Eronen@nokia.com wrote: > > (wearing Area Director hat) > > > > Although the IETF Last Call is still underway, here's a short attempt > > to summarize the discussion regarding identity changes (Section 7) so > > far: > > > > - We seem to agree that changing the certificate/identity > > during secure renegotiation (so there's no man-in-the-middle, just > two > > parties) could confuse some applications. James Manger's email > provides > > IMHO a good example of what that confusion could be (in this > particular > > example, the confusion has security implications, too): > > > > http://www.ietf.org/mail-archive/web/tls/current/msg05122.html > > > > - We mostly seem to agree that some applications could not just > handle > > certificate/identity changes correctly, but would actually benefit > > from them. > > > > - We seem to agree that it would be a reasonable idea for the TLS > > library to offer the applications an option where the TLS library > > checks that the certificate doesn't change during renegotiation. > > This is an *option* -- an application could decide not to use it, > > and e.g. do more complex comparisons. > > > > - We have much less support for requiring that every TLS library > > MUST implement this functionality and/or MUST enable it by default > > (whatever "by default" means in your API), at least in this draft. > > > > Unless I'm badly misreading the situation, or it significantly > changes > > during the rest of the IETF Last Call, my proposal here would be as > > follows: > > > > - We do NOT require (with "MUST") any changes to TLS libraries in > this > > regard. > > > > - We describe the situation a bit more clearly than the current text > > does (it seems many people found the current text somewhat unclear). > > > > - We recommend that TLS libraries SHOULD provide identity matching > > (with memcmp, abort handshake if changed) functionality to > > applications, and SHOULD allow applications to enable/disable this > > functionality. > > > > - We include a sentence or two describing the pros and cons of > > enabling/not enabling this feature by default, but don't require or > > recommend any particular default value. > > > > - The text probably needs to note that if the applications wants to > > deal with identity changes, it may need to consider the "which > > application_data byte(s) correspond to which identity" question (or > it > > may not -- the answer may depend a lot on the application protocol). > > > > Does this sound like a reasonable approach? > > > > Best regards, > > Pasi > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > From mrex@sap.com Tue Dec 8 05:47: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 A1ED03A69BB for ; Tue, 8 Dec 2009 05:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 BNv9y60p-m8p for ; Tue, 8 Dec 2009 05:47:55 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A26333A683B for ; Tue, 8 Dec 2009 05:47:54 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB8Dlg3f014626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 14:47:42 +0100 (MET) From: Martin Rex Message-Id: <200912081347.nB8Dlf2g010663@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Tue, 8 Dec 2009 14:47:41 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4FCB4@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 09:50:27 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] Last Call: draft-ietf-tls-renegotiation (Transport Layer 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, 08 Dec 2009 13:47:55 -0000 Pasi.Eronen@nokia.com wrote: > > Martin Rex wrote: > > Chris Newman wrote: > > > > > 1. Running code: multiple implementations and interop testing was > > > performed on an earlier version of draft-ietf-tls-renegotiation. > > > > Even EKR admitted that implementing the update is an insignificant > > amount of work. > > Martin: Do you agree with EKR here or not? > > (I guess "the update" here means "any of the proposed variants"). Implementing original TLS extension RI draft and my current one is about the same amount of work (but results in double the amount of code for TLS extensions RI draft for implementations that _already_have_ TLS extensions support, much more for those that don't). When MCSV is implemented and special cases are addressed, then TLS extensions RI is a little more work. The big difference comes with testing (which any reasonable QA can not simply ignore). The amount of testing required for TLS extension RI is significantly higher than it is for my approach, simply because all the code that I added is used all the time during regular interop tests, there are hardly any special cases in mine. -Martin From ekr@networkresonance.com Tue Dec 8 07: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 B1D023A6884 for ; Tue, 8 Dec 2009 07:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=0.037, 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 PYW5uMyj4njQ for ; Tue, 8 Dec 2009 07:30: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 B7A0D3A6803 for ; Tue, 8 Dec 2009 07:30:43 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 1B1BB6C5330; Tue, 8 Dec 2009 07:32:22 -0800 (PST) Date: Tue, 08 Dec 2009 07:32:21 -0800 From: Eric Rescorla To: Stephen Farrell In-Reply-To: <4B1E4E10.90201@cs.tcd.ie> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@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: <20091208153223.1B1BB6C5330@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 15:30:44 -0000 I'm fine with this general approach, but I'd also be fine with (a slightly modified version of) Stephen's suggestion, namely to to leave out any normative text but provide some descriptive text. -Ekr At Tue, 8 Dec 2009 13:01:04 +0000, Stephen Farrell wrote: > > > Hi Pasi, > > I think that all sounds ok, except I don't see any mention > in your summary of the fact that a bunch of people (incl. me) > said that this just shouldn't be part of the re-negotiation > fix. Maybe some of those have changed their minds as a result > of the discussion though, I've not checked. > > If the consensus ends up being to include some text about > this, then your approach below sounds ok to me, (though > I'd be a bit worried it might take a while to get the > right text), but I'd still rather leave it out entirely > and have some other document address the identity-change > issue in a more considered manner. > > S. > > Pasi.Eronen@nokia.com wrote: > > (wearing Area Director hat) > > > > Although the IETF Last Call is still underway, here's a short attempt > > to summarize the discussion regarding identity changes (Section 7) so > > far: > > > > - We seem to agree that changing the certificate/identity > > during secure renegotiation (so there's no man-in-the-middle, just two > > parties) could confuse some applications. James Manger's email provides > > IMHO a good example of what that confusion could be (in this particular > > example, the confusion has security implications, too): > > > > http://www.ietf.org/mail-archive/web/tls/current/msg05122.html > > > > - We mostly seem to agree that some applications could not just handle > > certificate/identity changes correctly, but would actually benefit > > from them. > > > > - We seem to agree that it would be a reasonable idea for the TLS > > library to offer the applications an option where the TLS library > > checks that the certificate doesn't change during renegotiation. > > This is an *option* -- an application could decide not to use it, > > and e.g. do more complex comparisons. > > > > - We have much less support for requiring that every TLS library > > MUST implement this functionality and/or MUST enable it by default > > (whatever "by default" means in your API), at least in this draft. > > > > Unless I'm badly misreading the situation, or it significantly changes > > during the rest of the IETF Last Call, my proposal here would be as > > follows: > > > > - We do NOT require (with "MUST") any changes to TLS libraries in this > > regard. > > > > - We describe the situation a bit more clearly than the current text > > does (it seems many people found the current text somewhat unclear). > > > > - We recommend that TLS libraries SHOULD provide identity matching > > (with memcmp, abort handshake if changed) functionality to > > applications, and SHOULD allow applications to enable/disable this > > functionality. > > > > - We include a sentence or two describing the pros and cons of > > enabling/not enabling this feature by default, but don't require or > > recommend any particular default value. > > > > - The text probably needs to note that if the applications wants to > > deal with identity changes, it may need to consider the "which > > application_data byte(s) correspond to which identity" question (or it > > may not -- the answer may depend a lot on the application protocol). > > > > Does this sound like a reasonable approach? > > > > Best regards, > > Pasi > > _______________________________________________ > > 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 Tue Dec 8 07: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 1CF2D28C166 for ; Tue, 8 Dec 2009 07:31:00 -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 tF6pLOfRvfyS for ; Tue, 8 Dec 2009 07:30: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 ADC4028C162 for ; Tue, 8 Dec 2009 07:30: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 1NI21X-00007c-PX; Tue, 08 Dec 2009 15:30:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4771D603A; Tue, 8 Dec 2009 15:30: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/TL80u9iyPaLurA9kkRYrmkQBW2iYf3+c= Message-ID: <4B1E7124.1040301@extendedsubset.com> Date: Tue, 08 Dec 2009 09:30:44 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com, "tls@ietf.org" References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@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 Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 15:31:00 -0000 Pasi.Eronen@nokia.com wrote: > (wearing Area Director hat) > > Although the IETF Last Call is still underway, here's a short attempt > to summarize the discussion regarding identity changes (Section 7) > so far: > > - We seem to agree that changing the certificate/identity during > secure renegotiation (so there's no man-in-the-middle, just two > parties) could confuse some applications. James Manger's email > provides IMHO a good example of what that confusion could be (in this > particular example, the confusion has security implications, too): > > http://www.ietf.org/mail-archive/web/tls/current/msg05122.html > > - We mostly seem to agree that some applications could not just > handle certificate/identity changes correctly, but would actually > benefit from them. There are probably some actively using it. > - We seem to agree that it would be a reasonable idea for the TLS > library to offer the applications an option where the TLS library Are there other actual accepted RFCs that provide recommendations for libraries? In a quick search, I could only find one or two uses of the term in the sense we use it here. Most were something like: RFC 4589 Location Types Registry: > library: Library or other public place in which literary and > artistic materials, such as books, music, periodicals, newspapers, > pamphlets, prints, records, and tapes, are kept for reading, > reference, or lending. > checks that the certificate doesn't change during renegotiation. This > is an *option* -- an application could decide not to use it, and e.g. > do more complex comparisons. There are lots of things a TLS library could do. Some of them are absolutely essential for correctness, but we are not addressing them here. > - We have much less support for requiring that every TLS library MUST > implement this functionality and/or MUST enable it by default > (whatever "by default" means in your API), at least in this draft. My guess is that such wording would largely be ignored. > Unless I'm badly misreading the situation, or it significantly > changes during the rest of the IETF Last Call, my proposal here would > be as follows: > > - We do NOT require (with "MUST") any changes to TLS libraries in > this regard. +1 > - We describe the situation a bit more clearly than the current text > does (it seems many people found the current text somewhat unclear). OK > - We recommend that TLS libraries SHOULD provide identity matching > (with memcmp, abort handshake if changed) functionality to > applications, and SHOULD allow applications to enable/disable this > functionality. Do we know that this is the correct way to compare certificates for most applications? Isn't this the first time TLS has recommended something that wouldn't work on a perpetual connection? After all, certificates update a lot more often than record sequence numbers wrap but the spec suggests a solution for that (renegotiation) rather than breaking the connection. > - We include a sentence or two describing the pros and cons of > enabling/not enabling this feature by default, but don't require or > recommend any particular default value. I'm not convinced that we understand the pros and cons well enough to be making recommendations. If we can't even recommend a default value, what business do we have making recommendations at all? > - The text probably needs to note that if the applications wants to > deal with identity changes, it may need to consider the "which > application_data byte(s) correspond to which identity" question (or > it may not -- the answer may depend a lot on the application > protocol). To some extent, this fix addresses it by ensuring that it's the same part on the other end for the entire connection. To the extent it does not, it remains a deep problem (e.g., it breaks printf/scanf() over TLS.) > Does this sound like a reasonable approach? Yes, but there are lots of reasonable things we could say. Putting something in when it does not need to be there, however well-intentioned, will have side effects. If nothing else, implementors have to read it and decide its implications internally. The need is immediate for a one-bug-fix document, so I feel we must be vigilant about keeping it minimal. * Is there a compelling need for this? I.e., is any of this worth risking delay for the remainder of the document? * Does it mandate any specific behavior relevant to the primary goal of the document? Would there be a loss to the rest of the document if it were removed? * Is it within the scope of the current related standards? Looks to me like library interfaces are new territory. * Are the people who need to know IETF's recommendations for TLS library interfaces going to look for them in this document? * Is this document the best place for it? (or does this document just happen to be the next train leaving the station) If the answer to some of these is 'no' then couldn't some of it be eliminated? - Marsh From marsh@extendedsubset.com Tue Dec 8 07: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 1834228C169 for ; Tue, 8 Dec 2009 07:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 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 X3jGn2+zfsFK for ; Tue, 8 Dec 2009 07:38: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 3A6FB28C166 for ; Tue, 8 Dec 2009 07:38:50 -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 1NI299-0007qO-ET; Tue, 08 Dec 2009 15:38:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 43462603A; Tue, 8 Dec 2009 15:38: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+HdLpc8TVBUMj7ReuT2beuTihrfyyeU/o= Message-ID: <4B1E72FC.9020408@extendedsubset.com> Date: Tue, 08 Dec 2009 09:38:36 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dr Stephen Henson References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <4B1E4AFA.7060600@drh-consultancy.demon.co.uk> In-Reply-To: <4B1E4AFA.7060600@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] Closing some open comments on 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, 08 Dec 2009 15:38:51 -0000 Dr Stephen Henson wrote: > Eric Rescorla wrote: >> I'll also make whatever small editorial changes I see. If I've >> missed something important that people think there is consensus on, >> please let me know. There are a lot of messages, so I may well >> have. >> > > In 6.1: > > If clients wish to ensure that such attacks are impossible, they MUST > terminate the connection immediately upon failure to receive the > extension without completing the handshake. > > Should we be more specific about what "terminate the connection" > means? Does that mean drop the connection immediately without sending > anything else or by sending a fatal alert? The spec says "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection." > If a fatal alert which one? Presumably handshake_failure? How about 'unexpected_message'? That's what I see when mixing application data into a renegotiation handshake that wasn't expecting it. RFC 4346 defines it as: > unexpected_message An inappropriate message was received. This alert > is always fatal and should never be observed in communication between > proper implementations. > I'm thinking here in terms of sending something useful which would > most likely appear in server logs to help diagnose the cause: i.e. > unpatched server which strict clients refuse to connect to. That would seem to set off the appropriate alarm bells. - Marsh From marsh@extendedsubset.com Tue Dec 8 08:02: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 BBFF028C168 for ; Tue, 8 Dec 2009 08:02:01 -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 obJN85G6-XEt for ; Tue, 8 Dec 2009 08:02: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 D5B1928C152 for ; Tue, 8 Dec 2009 08:02:00 -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 1NI2VZ-000Gew-Tm; Tue, 08 Dec 2009 16:01:50 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F0616603A; Tue, 8 Dec 2009 16:01: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: U2FsdGVkX18ePzT2XGPoN0Gf6CqMmIW09MkQV2XF01c= Message-ID: <4B1E786A.7070100@extendedsubset.com> Date: Tue, 08 Dec 2009 10:01:46 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@cs.tcd.ie> <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 16:02:01 -0000 Pasi.Eronen@nokia.com wrote: > The security considerations section of this draft has to describe the > fact that even with this fix, renegotiation does things that will > surprise application developers, Does it? This fix ensures that the same party is on each end for the entire connection. This rules out a MitM switching connections around. So the only remaining issues must involve a client or server being able to switch between certificates that he actually does have the private key for. Clients are already expected to validate the server cert for any protection. My impression is that the most surprising thing about renegotiation for most app developers is that it can happen at all, and that their TLS library may be silently handling it by default. If we make any recommendations for TLS libraries it should be to not do renegotiation unless the application asks for it by registering a callback. > and can cause security > vulnerabilities for some of them. Do we know of any examples? I can only think of some very subtle and hypothetical ones that require client and server apps that are already coded for switching identities intentionally. > That part we cannot avoid -- some text has to be included. > > It's not absolutely required that the text makes recommendations how > to avoid those vulnerabilities, but IMHO it would be a bit strange to > just describe the security problem without saying anything how to > avoid it... Any security problems which remain after MitM renegotiation is fixed will be interesting to research, but I just don't think we understand them well enough yet to describe them in an official document. - Marsh From mrex@sap.com Tue Dec 8 08:11: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 454BF28C1F4 for ; Tue, 8 Dec 2009 08:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 EXId3kPFXI+1 for ; Tue, 8 Dec 2009 08:11: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 2091B28C1F2 for ; Tue, 8 Dec 2009 08:11:39 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB8GBQI5002564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 17:11:26 +0100 (MET) From: Martin Rex Message-Id: <200912081611.nB8GBQ8a019273@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Tue, 8 Dec 2009 17:11:26 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 02:12:07 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] Summarizing identity change discussion so far 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, 08 Dec 2009 16:11:42 -0000 Pasi.Eronen@nokia.com wrote: > > The security considerations section of this draft has to describe the > fact that even with this fix, renegotiation does things that will > surprise application developers, and can cause security > vulnerabilities for some of them. > > That part we cannot avoid -- some text has to be included. > > It's not absolutely required that the text makes recommendations how > to avoid those vulnerabilities, but IMHO it would be a bit strange to > just describe the security problem without saying anything how to > avoid it... I agree with this reasoning. Given the contention on this topic, I would prefer the guidance to be: - non-normative on default behaviour - normative (SHOULD) on specific options a TLS implementation should offer to applications Two options where identifying the exact location of renegotiation in app-data is not necessary and interleaving of app-data and renegotiation handshake is not a security problem: - no renegotiation - renegotiation only for identical certificate (chain) = memcmp() (allowing authentication of a previously un-authenticated party) Defining constraints for changes in identity where the application has to deal with these changes becomes complex very quickly. When there is some signaling between TLS implementation and application (like a callback), and application data that arrives during the renegotiation handshake is either dropped or leads to failed hanshake, then a change of identity--even for something as "insignificant" as a certificate renewal is manageable for the application. There are issues in the existing SSL & TLS protocol specs that cause a problem for such semantics: (a) the TLS spec explicitly allows transfer of application messages interleaved with renegotiation handshake messages, and (b) the TLS spec indicates that handshake messages have precedence over application data, without saying what this means. Since this precedence is _not_ about processing at the record layer (in TLS, all messages must be processed in order), so it can only be about delivery to application. But here, it creates a confusion in the wrong direction. Application data delivered interleaved with the renegotiation handshake is protected under the original cipher suite and under the original authentication. Delaying that data until after authentication seems unreasonable, because it would require an additional facility to tell the application at what point in the application data stream the identity change happened, long after the signaling of the new identity. When application data delivery is allowed during renegotiation handshake and the identity change signaling is _NOT_ after successful verification of the peer's finished messsage, but instead is performed much earlier in the handshake (such as during processing of the Certificate handshake message), then this may easily create additional security problems for an application. -Martin From lists@drh-consultancy.demon.co.uk Tue Dec 8 09:02: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 8CBA73A6A16 for ; Tue, 8 Dec 2009 09:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_24=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 82Ol+7JaocHn for ; Tue, 8 Dec 2009 09:02:00 -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 482E53A68B7 for ; Tue, 8 Dec 2009 09:02:00 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49203 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 1NI3RX-0001pa-2m (return-path ); Tue, 08 Dec 2009 17:01:45 +0000 Message-ID: <4B1E8679.4000200@drh-consultancy.demon.co.uk> Date: Tue, 08 Dec 2009 17:01:45 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marsh Ray References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <4B1E4AFA.7060600@drh-consultancy.demon.co.uk> <4B1E72FC.9020408@extendedsubset.com> In-Reply-To: <4B1E72FC.9020408@extendedsubset.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] Closing some open comments on 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, 08 Dec 2009 17:02:01 -0000 Marsh Ray wrote: > Dr Stephen Henson wrote: >> Eric Rescorla wrote: >>> I'll also make whatever small editorial changes I see. If I've >>> missed something important that people think there is consensus on, >>> please let me know. There are a lot of messages, so I may well >>> have. >>> >> In 6.1: >> >> If clients wish to ensure that such attacks are impossible, they MUST >> terminate the connection immediately upon failure to receive the >> extension without completing the handshake. >> >> Should we be more specific about what "terminate the connection" >> means? Does that mean drop the connection immediately without sending >> anything else or by sending a fatal alert? > > The spec says "Upon transmission or receipt of a fatal alert message, > both parties immediately close the connection." > >> If a fatal alert which one? Presumably handshake_failure? > > How about 'unexpected_message'? That's what I see when mixing > application data into a renegotiation handshake that wasn't expecting it. > Just to be clear here: I'm not referring to an attack but where we have a strict patched client that refuses to connect to an unpatched server. That is client makes initial handshake using RI+MCSV, doesn't get RI back and decides this is not acceptable. This is a scenario which is quite likely to happen at some point. Well it happens already in my test environment ;-) I'm asking whether a client should send a fatal alert here so a server admin can get some hint of the cause or if it should just silently drop the connection. 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 Dec 8 09:24: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 D0CE03A6A1B for ; Tue, 8 Dec 2009 09:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_24=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 rWxGLYoRylHI for ; Tue, 8 Dec 2009 09:24: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 D96683A6A26 for ; Tue, 8 Dec 2009 09:24:24 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB8HOA9k000984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 18:24:10 +0100 (MET) From: Martin Rex Message-Id: <200912081724.nB8HO9RE023884@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Tue, 8 Dec 2009 18:24:09 +0100 (MET) In-Reply-To: <4B1E8679.4000200@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Dec 8, 9 05:01: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] Closing some open comments on 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, 08 Dec 2009 17:24:25 -0000 Dr Stephen Henson wrote: > > Just to be clear here: I'm not referring to an attack but where we have > a strict patched client that refuses to connect to an unpatched server. > That is client makes initial handshake using RI+MCSV, doesn't get RI > back and decides this is not acceptable. > > This is a scenario which is quite likely to happen at some point. Well it > happens already in my test environment ;-) > > I'm asking whether a client should send a fatal alert here so a server > admin can get some hint of the cause or if it should just silently > drop the connection. If this were a _new_ spec, then I would suggest a SHOULD. But since we're going back in time, and there seem to be a number of implementations that are notoriously bad and sending and receiving SSL alerts, I definitely would not want to create any false hopes. In the situation that you're describing, it is the updated client that determines that it doesn't want continue talking to the old server, and so the set of available Alerts that could make any sense to an old server is those known to SSLv3, IMHO. -Martin From marsh@extendedsubset.com Tue Dec 8 09:25: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 5C4033A6A36 for ; Tue, 8 Dec 2009 09:25:36 -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 hvyY4HaXCfXU for ; Tue, 8 Dec 2009 09:25: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 812933A6A18 for ; Tue, 8 Dec 2009 09:25: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 1NI3oQ-0005un-TA; Tue, 08 Dec 2009 17:25:24 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C22A3603A; Tue, 8 Dec 2009 17:25:20 +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+Lo+sj2Ujqe0Aw2uC3dr+T8zGZJV48HD4= Message-ID: <4B1E8BFE.6090506@extendedsubset.com> Date: Tue, 08 Dec 2009 11:25:18 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dr Stephen Henson References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <4B1E4AFA.7060600@drh-consultancy.demon.co.uk> <4B1E72FC.9020408@extendedsubset.com> <4B1E8679.4000200@drh-consultancy.demon.co.uk> In-Reply-To: <4B1E8679.4000200@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] Closing some open comments on 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, 08 Dec 2009 17:25:36 -0000 Dr Stephen Henson wrote: > > I'm asking whether a client should send a fatal alert here so a server admin can > get some hint of the cause or if it should just silently drop the connection. I can't find anywhere in the current RFCs that advocate silently dropping the connection. In fact it defines it in the opposite direction: > Error handling in the TLS Handshake protocol is very simple. When an > error is detected, the detecting party sends a message to the other > party. Upon transmission or receipt of a fatal alert message, both > parties immediately close the connection. Servers and clients MUST > forget any session-identifiers, keys, and secrets associated with a > failed connection. Thus, any connection terminated with a fatal > alert MUST NOT be resumed. As a TLS library, you might not always have an actual socket handle. It may be require rarely-used code in the application to actually "close the connection". Application code may not always tell you when a socket has been closed, so you may not have the opportunity to clean up and/or log messages about the event. I think using the currently defined fatal alert protocol is appropriate here. - Marsh From stefan@aaa-sec.com Tue Dec 8 11:11: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 EEC8F3A6A4C for ; Tue, 8 Dec 2009 11:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.108, 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 nDJViyBk1ksY for ; Tue, 8 Dec 2009 11:11:57 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id C16DB3A693F for ; Tue, 8 Dec 2009 11:11:56 -0800 (PST) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 47E93289CF3 for ; Tue, 8 Dec 2009 20:11:51 +0100 (CET) Received: (qmail 58329 invoked from network); 8 Dec 2009 19:11: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 s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Dec 2009 19:11:43 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 08 Dec 2009 20:11:41 +0100 From: Stefan Santesson To: , Message-ID: Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp4BoPJVyVgAyqSSPeFPl2hJhz35gAACQzwAAznfMo= In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 19:11:59 -0000 Pasi, On 09-12-08 2:12 PM, "Pasi.Eronen@nokia.com" wrote: > It's not absolutely required that the text makes recommendations how > to avoid those vulnerabilities, but IMHO it would be a bit strange to > just describe the security problem without saying anything how to > avoid it... Following the BCP on how to write security considerations it seems perfectly valid to point out a security issue and to declare it out of scope for the present document to handle. /Stefan From Pasi.Eronen@nokia.com Tue Dec 8 11:52:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626113A68A2 for ; Tue, 8 Dec 2009 11:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 kRF7fOavMNIZ for ; Tue, 8 Dec 2009 11:52:29 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DA54B3A676A for ; Tue, 8 Dec 2009 11:52:28 -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 nB8JjpII018087; Tue, 8 Dec 2009 21:45:53 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 21:45:51 +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); Tue, 8 Dec 2009 21:45:51 +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; Tue, 8 Dec 2009 20:45:50 +0100 From: To: Date: Tue, 8 Dec 2009 20:45:49 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp4H8nHqDegJlrBRyOiurK/Ct5rzgAGqeuw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@cs.tcd.ie> <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E786A.7070100@extendedsubset.com> In-Reply-To: <4B1E786A.7070100@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2009 19:45:51.0519 (UTC) FILETIME=[0C2032F0:01CA783F] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 19:52:30 -0000 TWFyc2ggUmF5IHdyb3RlOg0KDQo+IFBhc2kuRXJvbmVuQG5va2lhLmNvbSB3cm90ZToNCj4gPiBU aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiB0aGlzIGRyYWZ0IGhhcyB0byBk ZXNjcmliZSB0aGUNCj4gPiBmYWN0IHRoYXQgZXZlbiB3aXRoIHRoaXMgZml4LCByZW5lZ290aWF0 aW9uIGRvZXMgdGhpbmdzIHRoYXQgd2lsbA0KPiA+IHN1cnByaXNlIGFwcGxpY2F0aW9uIGRldmVs b3BlcnMsDQo+IA0KPiBEb2VzIGl0PyBUaGlzIGZpeCBlbnN1cmVzIHRoYXQgdGhlIHNhbWUgcGFy dHkgaXMgb24gZWFjaCBlbmQgZm9yIHRoZQ0KPiBlbnRpcmUgY29ubmVjdGlvbi4NCj4gDQo+IFRo aXMgcnVsZXMgb3V0IGEgTWl0TSBzd2l0Y2hpbmcgY29ubmVjdGlvbnMgYXJvdW5kLiBTbyB0aGUg b25seQ0KPiByZW1haW5pbmcgaXNzdWVzIG11c3QgaW52b2x2ZSBhIGNsaWVudCBvciBzZXJ2ZXIg YmVpbmcgYWJsZSB0byBzd2l0Y2gNCj4gYmV0d2VlbiBjZXJ0aWZpY2F0ZXMgdGhhdCBoZSBhY3R1 YWxseSBkb2VzIGhhdmUgdGhlIHByaXZhdGUga2V5IGZvci4NCj4gQ2xpZW50cyBhcmUgYWxyZWFk eSBleHBlY3RlZCB0byB2YWxpZGF0ZSB0aGUgc2VydmVyIGNlcnQgZm9yIGFueQ0KPiBwcm90ZWN0 aW9uLg0KPiANCj4gTXkgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSBtb3N0IHN1cnByaXNpbmcgdGhp bmcgYWJvdXQgcmVuZWdvdGlhdGlvbiBmb3INCj4gbW9zdCBhcHAgZGV2ZWxvcGVycyBpcyB0aGF0 IGl0IGNhbiBoYXBwZW4gYXQgYWxsLCBhbmQgdGhhdCB0aGVpciBUTFMNCj4gbGlicmFyeSBtYXkg YmUgc2lsZW50bHkgaGFuZGxpbmcgaXQgYnkgZGVmYXVsdC4gSWYgd2UgbWFrZSBhbnkNCj4gcmVj b21tZW5kYXRpb25zIGZvciBUTFMgbGlicmFyaWVzIGl0IHNob3VsZCBiZSB0byBub3QgZG8gcmVu ZWdvdGlhdGlvbg0KPiB1bmxlc3MgdGhlIGFwcGxpY2F0aW9uIGFza3MgZm9yIGl0IGJ5IHJlZ2lz dGVyaW5nIGEgY2FsbGJhY2suDQoNCkkgdGhpbmsgdGhlIGZhY3QgdGhhdCAiZ2V0UGVlckNlcnRp ZmljYXRlKCkiIGFuZCBzaW1pbGFyIEFQSSBjYWxscw0KY2FuIHJldHVybiBhIGRpZmZlcmVudCB2 YWx1ZSBlYWNoIHRpbWUgdGhleSdyZSBjYWxsZWQgd291bGQgYmUgYQ0Kc3VycHJpc2UgdG8gbW9z dCBhcHAgZGV2ZWxvcGVycy4NCg0KPiA+IGFuZCBjYW4gY2F1c2Ugc2VjdXJpdHkgdnVsbmVyYWJp bGl0aWVzIGZvciBzb21lIG9mIHRoZW0uDQo+IA0KPiBEbyB3ZSBrbm93IG9mIGFueSBleGFtcGxl cz8gSSBjYW4gb25seSB0aGluayBvZiBzb21lIHZlcnkgc3VidGxlIGFuZA0KPiBoeXBvdGhldGlj YWwgb25lcyB0aGF0IHJlcXVpcmUgY2xpZW50IGFuZCBzZXJ2ZXIgYXBwcyB0aGF0IGFyZSBhbHJl YWR5DQo+IGNvZGVkIGZvciBzd2l0Y2hpbmcgaWRlbnRpdGllcyBpbnRlbnRpb25hbGx5Lg0KDQpX ZWxsLCBhbHRob3VnaCB0aGUgZXhhbXBsZSBpbiBKYW1lcyBNYW5nZXIncyBlbWFpbCBpcyBub3Qg cmVhbCAoaW4gdGhlDQpzZW5zZSB0aGF0IGl0J3Mgbm90IGZyb20gcmVhbCBjb2RlKSwgSSB0aGlu ayBpdCdzIHBsYXVzaWJsZSwgYW5kIGl0DQpkb2Vzbid0IGludm9sdmUgYW4gYXBwIGFscmVhZHkg Y29kZWQgZm9yIHN3aXRjaGluZyBpZGVudGl0aWVzDQppbnRlbnRpb25hbGx5Lg0KDQpJIGd1ZXNz IGFuIGV2ZW4gd29yc2UgZXhhbXBsZSB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQog IGNvbm4gPSBvcGVuVGxzQ29ubmVjdGlvbihob3N0LCBwb3J0KQ0KICBpZiBub3QgdmVyaWZ5Q2Vy dENoYWluKGNvbm4uZ2V0UGVlckNlcnQoKSk6DQogICAgIHJhaXNlICJOb3QgYSB2YWxpZCBjZXJ0 Ig0KICBpZiBjb25uLmdldFBlZXJDZXJ0KCkuZ2V0TmFtZSgpICE9IGV4cGVjdGVkX25hbWU6DQog ICAgIHJhaXNlICJOYW1lIGluIGNlcnRpZmljYXRlIGRvZXNuJ3QgbWF0Y2giDQogICMgY29udGlu dWUuLi4NCg0KTW9zdCBUTFMgbGlicmFyaWVzIHNlZW0gdG8gc3VwcG9ydCBib3RoIGNhbGxiYWNr IGFuZCBnZXQoKSBzdHlsZQ0KZnVuY3Rpb25zIGZvciBhY2Nlc3NpbmcvY2hlY2tpbmcgY2VydGlm aWNhdGVzLg0KDQpBbHRob3VnaCB1c2luZyB0aGUgY2FsbGJhY2stc3R5bGUgQVBJcyBtaWdodCBi ZSBtb3JlIGNvbW1vbiAoYW5kIGluDQpzb21lIHNlbmNlIG5pY2VyLCBzaW5jZSBpdCBhbGxvd3Mg eW91IHRvIGFib3J0IHRoZSBoYW5kc2hha2UgDQphIGJpdCBlYXJsaWVyIC0tIGJ1dCBhbiBhcHAg ZGV2ZWxvcGVyIG1pZ2h0IG5vdCBjYXJlIGFib3V0IHRoaXMgdmVyeSANCm11Y2gpLCBJIHRoaW5r IGl0IHdvdWxkIGJlIGEgc3VycHJpc2UgdG8gbW9zdCBhcHAgZGV2ZWxvcGVycyB0aGF0IA0KdXNp bmcgdGhlIGdldC1zdHlsZSBBUElzIG1pZ2h0IG5vdCBiZSBzZWN1cmUuDQoNCihBbmQgSSB3b3Vs ZG4ndCBiZSBzdXJwcmlzZWQgYXQgYWxsIGlmIHJlYWwgYXBwbGljYXRpb25zIHVzaW5nDQp0aG9z ZSBnZXQoKSBzdHlsZSBBUElzIGFyZSBmb3VuZC4uLikgDQoNCkJlc3QgcmVnYXJkcywNClBhc2kN Cg0K From Pasi.Eronen@nokia.com Tue Dec 8 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 4F8B53A65A6 for ; Tue, 8 Dec 2009 12:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 LaJRQGCox-67 for ; Tue, 8 Dec 2009 12:07:09 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 11F5C3A6403 for ; Tue, 8 Dec 2009 12:07:08 -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 nB8K0MLI029427; Tue, 8 Dec 2009 22:00:35 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 22:00:27 +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); Tue, 8 Dec 2009 22:00:22 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 8 Dec 2009 21:00:22 +0100 From: To: , Date: Tue, 8 Dec 2009 21:00:20 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp4G3oN0NWhjB1DREe6/un+HKvWtgAI59Yg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D23932@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E7124.1040301@extendedsubset.com> In-Reply-To: <4B1E7124.1040301@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: 08 Dec 2009 20:00:22.0681 (UTC) FILETIME=[1360F890:01CA7841] X-Nokia-AV: Clean Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 20:07:10 -0000 Marsh Ray wrote: > Are there other actual accepted RFCs that provide recommendations for > libraries? In a quick search, I could only find one or two uses of the > term in the sense we use it here. Most were something like: Plenty, starting from the TLS specification itself (RFC 5246). For example: "These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange." (It's basically saying the TLS library MUST NOT enable this feature by default, unless the application explicitly asks for it via an API.) But I agree that the word "library" is very rarely used; it's much more common to talk about "implementation" or something like that.=20 Best regards, Pasi From mrex@sap.com Tue Dec 8 12:44: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 E1A4B3A692F for ; Tue, 8 Dec 2009 12:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 SYU0pMSo3q4H for ; Tue, 8 Dec 2009 12:44: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 9DB5A3A6918 for ; Tue, 8 Dec 2009 12:44:56 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB8Kig6o024740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 21:44:42 +0100 (MET) From: Martin Rex Message-Id: <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Tue, 8 Dec 2009 21:44:41 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 08:45:49 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] Summarizing identity change discussion so far 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, 08 Dec 2009 20:44:58 -0000 Pasi.Eronen@nokia.com wrote: > > Marsh Ray wrote: > > Pasi.Eronen@nokia.com wrote: > > > > > > The security considerations section of this draft has to describe the > > > fact that even with this fix, renegotiation does things that will > > > surprise application developers, I fully agree. > > > > Does it? This fix ensures that the same party is on each end for the > > entire connection. This rules out a MitM switching connections around. The secure TLS renegotiation _ONLY_ assures that the TLS endpoint can not be tranferred among different peers without their _consent_ during renegotiation. An MitM attacker is someone acting without consent. As long as switching of the identity is permitted during renegotiation (which it currently is), there is only a vague concept of "party" at the other end. > > > If we make any recommendations for TLS libraries it should be to > > not do renegotiation unless the application asks for it by > > registering a callback. Clients usually do _not_ want renegotiation, but they have no say in the TLS handshake. It is the Server which decides whether to ask for a certificate on the initial handshake or whether the server wants to make up his mind only after having seen the clients request. The issue is often usability / user-experience. If you ask a Browser for a certificate on the initial connect, it will result in a popup windows to the user, even if that user has no certificate. It is possible to configure the browser to suppress this popup, but often the browser has only a single configuration option that says "select automatically", and that does actually two different things, i.e. use a client certificate when the request from the server matches exactly one client cert -- an the latter is something one might want _not_ to happen automatically--in contrast to automatic reply that no client cert is available. > > I think the fact that "getPeerCertificate()" and similar API calls > can return a different value each time they're called would be a > surprise to most app developers. Definitely. > > Well, although the example in James Manger's email is not real (in the > sense that it's not from real code), I think it's plausible, and it > doesn't involve an app already coded for switching identities > intentionally. > > I guess an even worse example would be something like this: > > conn = openTlsConnection(host, port) > if not verifyCertChain(conn.getPeerCert()): > raise "Not a valid cert" > if conn.getPeerCert().getName() != expected_name: > raise "Name in certificate doesn't match" > # continue... > > Most TLS libraries seem to support both callback and get() style > functions for accessing/checking certificates. > > Although using the callback-style APIs might be more common (and in > some sence nicer, since it allows you to abort the handshake > a bit earlier -- but an app developer might not care about this very > much), I think it would be a surprise to most app developers that > using the get-style APIs might not be secure. > > (And I wouldn't be surprised at all if real applications using > those get() style APIs are found...) The get-style API is _the_only_ API that I provide to our applications. Besides, I'm coming from the GSS-API world, and there never was a callback API. If you think that get-style API is dangerous, then you seem to be quite unaware about the risks involved with some of the callback APIs (besides being difficult to use in distributed architectures). TLS peers should check the peer's ID before they start sending or receiving any data over the newly established TLS session. Apps protocols that infer from a successful TLS handshake that previously received plaintext data is authenticated suffer from a serious apps-level design flaw. Abusing GSS-API or TLS as an OTP plaintext authentication scheme is IMHO a severe APPS design flaw. The ability to complete a TLS handshake (or to establish a gssapi security context) does not, by itself, convey any kind of intent. Apps that infer intent from this, should really rethink their flawed architecture. -Martin From mickgray@au1.ibm.com Tue Dec 8 12:59: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 196C63A684E for ; Tue, 8 Dec 2009 12:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 zfNCGxIoy4Ql for ; Tue, 8 Dec 2009 12:59:37 -0800 (PST) Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by core3.amsl.com (Postfix) with ESMTP id 6F4753A677D for ; Tue, 8 Dec 2009 12:59:26 -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 nB8KuBf4008833 for ; Wed, 9 Dec 2009 07:56:11 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB8KxE1J1302556 for ; Wed, 9 Dec 2009 07:59:15 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB8KxDUv031145 for ; Wed, 9 Dec 2009 07:59:13 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB8KxCnn031123; Wed, 9 Dec 2009 07:59:13 +1100 In-Reply-To: <20091207220244.DA1A06C5242@kilo.networkresonance.com> To: Eric Rescorla X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Wed, 9 Dec 2009 06:40:48 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 09/12/2009 08:06:12 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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, 08 Dec 2009 20:59:38 -0000 Eric Rescorla wrote: > Hi folks, > > I've been going through the list discussion on > draft-ietf-tls-renegotiation and wanted to try to close on some of the > edits people have proposed. > > 1. Replace "cipher suite" with magic cipher suite value (MCSV) > throughout. > > 2. Add "Updates: RFC 5246, 4366, 4347". Pasi, should we be explicitly stating > 4346 and 2246? ISTM we already transitively update them, but I don't > care either way. > > 3. Rewrite the introduction along the lines suggested by Marsh Ray, > Nicolas Williams, David-Sarah Hopwood, and others to more accurately > capture the entities which are being spliced here. I will propose > new text on the list. > > 4. Channel bindings: replace the end of S 1. with: > > "The data used in the extension is similar to, but not the same as, the > channel binding data used in [I-D.altman-tls-channel-bindings], however > this extension is not a generic-purpose RFC 5056 channel binding > facility." > > Nico, did you have other text you wanted? > > 5. Explicitly state that this extension also applies to DTLS and > that the same normativity levels apply. > > 6. Explicitly state that this extension may also be used with > SSLv3 (we don't have any authority to update SSLv3 in any > way but we can certainly say that there is no technical > obstacle.) I would request that this needs to include sufficient technical details e.g. the size of the verify_data values etc. > > 7. Clarify that RI MUST be generated in all rehandshakes, per the > issue Martin raised earlier and proposed resolution by Marsh > and Nelson. > > 8. Rewrite the introduction to more clearly elucidate > the impact on app-level protocols. As Chris Newman has pointed > out it currently apples primarily to HTTPS, but we should have > some non-HTTPS text. I will propose new text on the list. > > 9. Rewrite the section about identity changes in Security Considerations. > I'll propose new text on the list. I additionally request guidance be included in Section 5 on safe probing of Servers during initial connection to prevent outages in environments that may include extension intolerant servers as per: Note : In cases where a ClientHello protocol behavior change from not sending extensions to sending extensions is a risk where legacy Servers may exist that are extension intolerant then the Client MAY mitigate this risk on initial connection by sending the TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST" and SHOULD NOT send the "renegotiation_info" extension unless the Client is sending other extensions. SA http://www.imc.org/ietf-tls/mail-archive/msg11082.html - Thanks - Mick Gray - IBM > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mickgray@au1.ibm.com Tue Dec 8 15:14:06 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741993A6919 for ; Tue, 8 Dec 2009 15:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 eDLYMKIOq3PE for ; Tue, 8 Dec 2009 15:14:05 -0800 (PST) Received: from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146]) by core3.amsl.com (Postfix) with ESMTP id CB9863A68DB for ; Tue, 8 Dec 2009 15:14:04 -0800 (PST) Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp04.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB8NAaCK004852 for ; Wed, 9 Dec 2009 10:10:36 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB8NDpkM1528038 for ; Wed, 9 Dec 2009 10:13:52 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB8NDpYq022868 for ; Wed, 9 Dec 2009 10:13:51 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB8NDplC022865 for ; Wed, 9 Dec 2009 10:13:51 +1100 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> To: X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Wed, 9 Dec 2009 09:13:36 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 09/12/2009 10:20:50 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 23:14:06 -0000 wrote: > The security considerations section of this draft has to describe the > fact that even with this fix, renegotiation does things that will > surprise application developers, and can cause security > vulnerabilities for some of them. > > That part we cannot avoid -- some text has to be included. > > It's not absolutely required that the text makes recommendations how > to avoid those vulnerabilities, but IMHO it would be a bit strange to > just describe the security problem without saying anything how to > avoid it... > I support the current wording in section 7 related to identity checking. However I think it would be preferable to replace MUST with SHOULD in that section. - Mick Gray - IBM > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Tue Dec 8 15:27: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 A8F5C3A6915 for ; Tue, 8 Dec 2009 15:27:07 -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 7dFpH7n8HUSX for ; Tue, 8 Dec 2009 15:27: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 87FFA3A683D for ; Tue, 8 Dec 2009 15:27: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 1NI9SJ-000BVQ-AI; Tue, 08 Dec 2009 23:26:55 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 783C8603A; Tue, 8 Dec 2009 23:26:53 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/wLZHbls/PTGr5mK2fwycXKG6B09/Mb+U= Message-ID: <4B1EE0BD.7020403@extendedsubset.com> Date: Tue, 08 Dec 2009 17:26:53 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp> In-Reply-To: <200912082044.nB8Kifxv006654@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2009 23:27:07 -0000 Martin Rex wrote: > > The secure TLS renegotiation _ONLY_ assures that the TLS endpoint > can not be tranferred among different peers without their _consent_ > during renegotiation. An MitM attacker is someone acting without consent. "Consent" isn't relevant, unless you're suggesting there are systems intentionally handing out secret key material. > As long as switching of the identity is permitted during renegotiation > (which it currently is), there is only a vague concept of > "party" at the other end. The remote party may be a physically hardened and tamper-resistant crypto module, or it may be some set of shared processes operating across a "cloud". In that sense it is nebulous, but that is outside the scope of the protocol. After this fix, the TLS concept of "remote party identity" becomes maximally "the identity established by the union of all valid and correct credentials validated during the establishment of a connection state on this connection, and transitively to all connections sharing at least one master_secret". For example, given the basic assumptions about the remote endpoint (it isn't pwned), you can believe all those credentials came from the same web browser. An application protocol is free to require its clients and servers to apply credentials more conservatively, of course. I suspect you would prefer application protocols to use a more minimal sense interpretation of identity, such as "the credentials validated during the establishment of just this one connection state". But this isn't sufficient for some uses of https and it is ambiguous for application data interleaved with handshake messages, so the maximal interpretation is actually better defined than yours. >>> If we make any recommendations for TLS libraries it should be to >>> not do renegotiation unless the application asks for it by >>> registering a callback. > > Clients usually do _not_ want renegotiation, but they have no say Some clients prefer renegotiation because they believe it lends confidentiality to the "public" client certificate. > in the TLS handshake. It is the Server which decides whether to > ask for a certificate on the initial handshake or whether the > server wants to make up his mind only after having seen the clients > request. Really it should be defined as part of any application protocol using TLS. > The issue is often usability / user-experience. If you ask a Browser > for a certificate on the initial connect, it will result in a popup > windows to the user, even if that user has no certificate. It > is possible to configure the browser to suppress this popup, > but often the browser has only a single configuration option > that says "select automatically", and that does actually two > different things, i.e. use a client certificate when the request > from the server matches exactly one client cert -- an the latter > is something one might want _not_ to happen automatically--in > contrast to automatic reply that no client cert is available. A. Yes, that's how browsers work. B. The number of applications which are "browsers" pop-up "choose a client cert" dialogs is small, I can think of four or five (actively maintained). This has got to be a tiny fraction of TLS client applications, even if it is the most visible and familiar for most people. > The get-style API is _the_only_ API that I provide to our applications. > Besides, I'm coming from the GSS-API world, and there never was > a callback API. > > If you think that get-style API is dangerous, then you seem to be > quite unaware about the risks involved with some of the callback APIs > (besides being difficult to use in distributed architectures). Then you can call the TLS library in a loop to invert the call. > TLS peers should check the peer's ID before they start sending > or receiving any data over the newly established TLS session. For current (pre-fix) https servers, the client's Finished message can be the most important thing it sends. > Apps protocols that infer from a successful TLS handshake that > previously received plaintext data is authenticated suffer from > a serious apps-level design flaw. > > Abusing GSS-API or TLS as an OTP plaintext authentication scheme > is IMHO a severe APPS design flaw. The ability to complete a > TLS handshake (or to establish a gssapi security context) > does not, by itself, convey any kind of intent. It's up to the app layer to define 'intent' the events exposed by the API, based on the stated and implied guarantees of the protocol spec. > Apps that infer intent from this, should really rethink their > flawed architecture. No, the design flaw was in SSLv3. It regressed on a fundamental security guarantee of SSLv2 and no one (including the spec writers) realized it at the time. - Marsh From mrex@sap.com Tue Dec 8 15:37: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 BA2503A683D for ; Tue, 8 Dec 2009 15:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 0xmjreixCAZK for ; Tue, 8 Dec 2009 15:37: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 BD7B93A681C for ; Tue, 8 Dec 2009 15:37:07 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB8NatUW008342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 00:36:55 +0100 (MET) From: Martin Rex Message-Id: <200912082336.nB8NatS7017577@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Wed, 9 Dec 2009 00:36:55 +0100 (MET) In-Reply-To: <20091207220244.DA1A06C5242@kilo.networkresonance.com> from "Eric Rescorla" at Dec 7, 9 02:02: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: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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, 08 Dec 2009 23:37:08 -0000 Eric Rescorla wrote: > > 6. Explicitly state that this extension may also be used with > SSLv3 (we don't have any authority to update SSLv3 in any > way but we can certainly say that there is no technical > obstacle.) What we're doing is giving recommendations to implementors what to do in their implementations when protocol version { 0x03, 0x00 } is negotiated. We do not need any formal authority to do so. I would suggest to mention the sizes of the SSLv3 finished messages (36 octets), since these are considerably larger than in TLS (12 octets). > > 7. Clarify that RI MUST be generated in all rehandshakes, per the > issue Martin raised earlier and proposed resolution by Marsh > and Nelson. Please add that this applies to _all_ handshakes, including TLS session resumes, i.e. the Server must return the TLS extension RI in the ServerHello of a TLS session resume as well! I feel a little uneasy with the term "rehandhshake". I assume you refer to "renegotiation", i.e. a handshake that is performed when the "current connection state" differs from "no encrytion, no compression, no MAC". I realize that the word "rehandshake" was added in one place to rfc5246 -- but I still would prefer a single term only. -Martin From mrex@sap.com Tue Dec 8 16:03: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 73A763A69BF for ; Tue, 8 Dec 2009 16:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 SuPWODA4GXjf for ; Tue, 8 Dec 2009 16:03: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 12A603A69B6 for ; Tue, 8 Dec 2009 16:03:14 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB9030A9009907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 01:03:00 +0100 (MET) From: Martin Rex Message-Id: <200912090002.nB902xlh019273@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 9 Dec 2009 01:02:59 +0100 (MET) In-Reply-To: <4B1EE0BD.7020403@extendedsubset.com> from "Marsh Ray" at Dec 8, 9 05:26: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 Subject: Re: [TLS] Summarizing identity change discussion so far 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, 09 Dec 2009 00:03:16 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > > The secure TLS renegotiation _ONLY_ assures that the TLS endpoint > > can not be tranferred among different peers without their _consent_ > > during renegotiation. An MitM attacker is someone acting without consent. > > "Consent" isn't relevant, unless you're suggesting there are systems > intentionally handing out secret key material. It is very relevant. Consenting communication peers can very well pass around TLS endpoints without the third communication party realizing that. Wait a minute -- the finished messages are _NOT_ secrets for the communication peers, and they are _NOT_ keying material. The MitM attacker knows perfectly well which Finished messages would be necessary to make a secure renegotiation work -- but he can not coerce unsuspecting TLS peers to uses these finished messages in the fashion that would be required to make a successful TLS handshake and deceive the third communication peer. The finished messages are "secure and unique session identifiers", and something that Nico wants to get his hands on for channel bindings. > > After this fix, the TLS concept of "remote party identity" becomes > maximally "the identity established by the union of all valid and > correct credentials validated during the establishment of a connection > state on this connection, and transitively to all connections sharing at > least one master_secret". > > For example, given the basic assumptions about the remote endpoint (it > isn't pwned), you can believe all those credentials came from the same > web browser. You do not know where that TLS endpoint is. What you do know is that with the secure TLS renegotiation, the TLS endpoint may no longer be transfered to unsuspecting communication peers. > > > TLS peers should check the peer's ID before they start sending > > or receiving any data over the newly established TLS session. > > For current (pre-fix) https servers, the client's Finished message can > be the most important thing it sends. You mean for the old TLS renegotiation when using client certificates? Yes, I believe so. > > > Apps protocols that infer from a successful TLS handshake that > > previously received plaintext data is authenticated suffer from > > a serious apps-level design flaw. > > > > Abusing GSS-API or TLS as an OTP plaintext authentication scheme > > is IMHO a severe APPS design flaw. The ability to complete a > > TLS handshake (or to establish a gssapi security context) > > does not, by itself, convey any kind of intent. > > It's up to the app layer to define 'intent' the events exposed by the > API, based on the stated and implied guarantees of the protocol spec. > > > Apps that infer intent from this, should really rethink their > > flawed architecture. > > No, the design flaw was in SSLv3. It regressed on a fundamental security > guarantee of SSLv2 and no one (including the spec writers) realized it > at the time. This comment was _not_ about TLS renegotiation. I was refering to concepts such as the HTTP-Negotiate authentication, which abuses GSS-API as a plaintext OTP-authentication scheme. -Martin From marsh@extendedsubset.com Tue Dec 8 16:17: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 BBA8F3A69CE for ; Tue, 8 Dec 2009 16:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWTcyevQxX0w for ; Tue, 8 Dec 2009 16:17:03 -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 4C3433A69C0 for ; Tue, 8 Dec 2009 16:17:03 -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 1NIAEe-0004SS-AR; Wed, 09 Dec 2009 00:16:52 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EEE27603A; Wed, 9 Dec 2009 00:16: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/wWWS2+DhjuiKXxsWHVJIn8KF1mc2iOkw= Message-ID: <4B1EEC70.5090205@extendedsubset.com> Date: Tue, 08 Dec 2009 18:16:48 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912082336.nB8NatS7017577@fs4113.wdf.sap.corp> In-Reply-To: <200912082336.nB8NatS7017577@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] Closing some open comments on 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: Wed, 09 Dec 2009 00:17:05 -0000 Martin Rex wrote: > > I feel a little uneasy with the term "rehandhshake". > I assume you refer to "renegotiation", i.e. a handshake that > is performed when the "current connection state" differs > from "no encrytion, no compression, no MAC". > > I realize that the word "rehandshake" was added in one place to > rfc5246 -- but I still would prefer a single term only. +1, it sounds like slightly loose terminology. Someone could easily think it referred to session resumption. There's also another section of proposed text where it emphasizes that every handshake must be considered independently of all others (signaling RI I think it was). The term "rehandshake" could be taken to imply that the same handshake is to be done again (whatever that would mean). - Marsh From ekr@networkresonance.com Tue Dec 8 16: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 7F2733A6803 for ; Tue, 8 Dec 2009 16:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.92 X-Spam-Level: X-Spam-Status: No, score=0.92 tagged_above=-999 required=5 tests=[AWL=0.025, 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, 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 yNrjJygmspFQ for ; Tue, 8 Dec 2009 16:26:46 -0800 (PST) Received: from kilo.networkresonance.com (216.156.83.78.ptr.us.xo.net [216.156.83.78]) by core3.amsl.com (Postfix) with ESMTP id 5AE1B3A68E4 for ; Tue, 8 Dec 2009 16:26:45 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C49576C55F6; Tue, 8 Dec 2009 16:28:26 -0800 (PST) Date: Tue, 08 Dec 2009 16:28:26 -0800 From: Eric Rescorla To: mrex@sap.com In-Reply-To: <200912082336.nB8NatS7017577@fs4113.wdf.sap.corp> References: <20091207220244.DA1A06C5242@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: <20091209002826.C49576C55F6@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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: Wed, 09 Dec 2009 00:26:47 -0000 At Wed, 9 Dec 2009 00:36:55 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > 6. Explicitly state that this extension may also be used with > > SSLv3 (we don't have any authority to update SSLv3 in any > > way but we can certainly say that there is no technical > > obstacle.) > > What we're doing is giving recommendations to implementors what > to do in their implementations when protocol version { 0x03, 0x00 } > is negotiated. We do not need any formal authority to do so. > > I would suggest to mention the sizes of the SSLv3 finished > messages (36 octets), since these are considerably larger than > in TLS (12 octets). I have no problem with any of this. I was just saying that this seems to be different from the situation with TLS where we can say you MUST do X, Y, and Z, and one could say that implementations were nonconformant if they did not. > > 7. Clarify that RI MUST be generated in all rehandshakes, per the > > issue Martin raised earlier and proposed resolution by Marsh > > and Nelson. > > > Please add that this applies to _all_ handshakes, including > TLS session resumes, i.e. the Server must return the > TLS extension RI in the ServerHello of a TLS session resume as well! Some text to this effect appears earlier, but I'm happy to add it here as well. > I feel a little uneasy with the term "rehandhshake". > I assume you refer to "renegotiation", i.e. a handshake that > is performed when the "current connection state" differs > from "no encrytion, no compression, no MAC". > > I realize that the word "rehandshake" was added in one place to > rfc5246 -- but I still would prefer a single term only. Good point. I'm fine with using renegotiation throughout. -Ekr From cfinss@dial.pipex.com Wed Dec 9 02:13: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 393773A68FF for ; Wed, 9 Dec 2009 02:13: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 rzzCD7TXb0i3 for ; Wed, 9 Dec 2009 02:13:33 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 4D81F3A67EC for ; Wed, 9 Dec 2009 02:13:33 -0800 (PST) X-Trace: 221938646/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.64/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.64 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEADcHH0s+vGRA/2dsb2JhbACDB4V1iFrEbwqCIoIABIFi X-IronPort-AV: E=Sophos;i="4.47,367,1257120000"; d="scan'208";a="221938646" X-IP-Direction: IN Received: from 1cust64.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.64]) by smtp.pipex.tiscali.co.uk with SMTP; 09 Dec 2009 10:13:20 +0000 Message-ID: <016301ca78af$fb916460$0601a8c0@allison> From: "tom.petch" To: "Nicolas Williams" References: <200912030002.nB3026Cg024685@fs4113.wdf.sap.corp><4B171AC0.6090403@jacaranda.org> <20091203221420.GZ773@Sun.COM><808FD6E27AD4884E94820BC333B2DB774F31A4F497@NOK-EUMSG-01.mgdnok.nokia.com><20091207163728.GH773@Sun.COM> <4B1D747E.1080001@jacaranda.org> <20091207213712.GM861@Sun.COM> Date: Wed, 9 Dec 2009 10:13:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: tls@ietf.org Subject: Re: [TLS] Defining "TLS channel" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 10:13:35 -0000 ----- Original Message ----- From: "Nicolas Williams" Sent: Monday, December 07, 2009 10:37 PM > On Mon, Dec 07, 2009 at 09:32:46PM +0000, David-Sarah Hopwood wrote: > > Nicolas Williams wrote: > > > If the re-negotiation bug is fixed then I'd say that re-negotiation does > > > not change the channel (same as in SSHv2, which never had this bug). > > > > > > If the re-negotiation bug is NOT fixed then I'd say that re-negotiation > > > does change the channel. > > > > I think this is a misunderstanding of the RFC5056 concept of "channel". > > Channel binding makes one channel cryptographically dependent on another; > > it does not identify them. > > There's "channel binding" the action (this is verb-like) and "channel > bindings" the data (this is noun-like). The data is very much like a > name for a channel: > > o Channel bindings: [See historical note below.] > > Generally, some data that "names" a channel or one or both of > its end-points such that if this data can be shown, at a higher > network layer, to be the same at both ends of a channel, then > there are no MITMs between the two end-points at that higher > network layer. This term is used as a noun. > > (That's from RFC5056, page 5. See also [Lampson91].) > > > >> This may have implications on what exactly the channel in RFC5056 > > >> sense would be. Or it may not -- the questions "what kind of > > >> abstraction TLS libraries should provide to applications" and "what > > >> should be 'channel' in RFC5056 sense" are certainly related, but not > > >> the same. > > > > > > If we wanted to believe that re-negotiation replaces an existing channel > > > with a different one then we wouldn't consider the re-negotiation bug a > > > bug. > > > > Yes, we would, because: > > > > - the channels are not bound, and they should be (even if they are > > presented to an application as separate streams). > > Following the fix they will be! The fact that they aren't bound *is* > the bug in re-negotiation that we're fixing. > > > - most TLS libraries present the channels as a single stream, and so > > applications using those libraries are vulnerable regardless of how > > many channel instances we should understand there to be. > > Not really. If the individual connections are chained by channel > binding, then the application need only make sure that they don't mix > them up (they have to anyways, in order to interop at all). It should > suffice that the TLS implementation chained all those connection by > channel binding them as described in whatever proposed solution to the > re-neg vuln becomes the proposed standard. Nico I don't think that channel binding is necessary. Rather, a secure channel provides integrity and, optionally, secrecy (as per RFC5056). A secure channel can change its security parameters, a new session key for example, but when doing so, must bind cryptographically (hate that phrase, never quite know if I really understand it) old and new together. In fact, channel binding as defined in RFC5056 would seem to exclude that case, so we need binding, but not channel binding. If there is no such binding, then we may still have a 'channel', but an insecure channel. Do we need that concept, or is the 'secure' implicit in all our references to channel? [And while I am at it, read the first paragraph of 'draft-altman-tls-channel-bindings-07.txt' and see if it refers to what it means to refer to.] Tom Petch > Nico From Pasi.Eronen@nokia.com Wed Dec 9 05: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 2EF9B3A67C2 for ; Wed, 9 Dec 2009 05:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 43ok8JJsvE1d for ; Wed, 9 Dec 2009 05:36:02 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E89633A67E1 for ; Wed, 9 Dec 2009 05:36:01 -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 nB9DZi6s004969; Wed, 9 Dec 2009 15:35: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, 9 Dec 2009 15:35:40 +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, 9 Dec 2009 15:35:35 +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; Wed, 9 Dec 2009 14:35:33 +0100 From: To: Date: Wed, 9 Dec 2009 14:35:31 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp4IR/RC00VyvXPR36LVBBx023MUQAsWbMA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D24088@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 02:12:07 pm <200912081611.nB8GBQ8a019273@fs4113.wdf.sap.corp> In-Reply-To: <200912081611.nB8GBQ8a019273@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: 09 Dec 2009 13:35:35.0362 (UTC) FILETIME=[7CAD6A20:01CA78D4] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 09 Dec 2009 13:36:03 -0000 Martin Rex wrote: > When there is some signaling between TLS implementation and application > (like a callback), and application data that arrives during the > renegotiation handshake is either dropped or leads to failed hanshake, > then a change of identity--even for something as "insignificant" as > a certificate renewal is manageable for the application. >=20 > There are issues in the existing SSL & TLS protocol specs that > cause a problem for such semantics: (a) the TLS spec explicitly allows > transfer of application messages interleaved with renegotiation > handshake messages, and (b) the TLS spec indicates that handshake > messages have precedence over application data, without saying > what this means. Since this precedence is _not_ about processing > at the record layer (in TLS, all messages must be processed in order), > so it can only be about delivery to application. But here, it > creates a confusion in the wrong direction. Application data delivered > interleaved with the renegotiation handshake is protected under the > original cipher suite and under the original authentication. > Delaying that data until after authentication seems unreasonable, > because it would require an additional facility to tell the application > at what point in the application data stream the identity change > happened, long after the signaling of the new identity. Even if application data and handshake messages were not interleaved over-the-wire, the application could still be confused. Let's assume some application data arrives just before the handshake (no interleaving over-the-wire); the TLS library reads it, decrypts it, and stores it in a buffer. But then the handshake starts before the application had a chance to read the data from the buffer (perhaps it's busy doing some else). After the handshake is done, the APIs may not really tell the application when exactly the data arrived... (This situation doesn't necessarily occur in all TLS libraries, and may depend on what the APIs look like, how threads are used, etc...) Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Wed Dec 9 05:40:36 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF0F3A6895 for ; Wed, 9 Dec 2009 05:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 mjSh04cflr5c for ; Wed, 9 Dec 2009 05:40:35 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A26373A67C2 for ; Wed, 9 Dec 2009 05:40:34 -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 nB9De38N013614; Wed, 9 Dec 2009 15:40:21 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:39:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:39:34 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 9 Dec 2009 14:39:33 +0100 From: To: Date: Wed, 9 Dec 2009 14:39:32 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp4R0mAs3G8WparTri1llpRksOp4AAjURlQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D24095@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 08:45:49 pm <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp> In-Reply-To: <200912082044.nB8Kifxv006654@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: 09 Dec 2009 13:39:34.0337 (UTC) FILETIME=[0B1E1B10:01CA78D5] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 09 Dec 2009 13:40:36 -0000 Martin Rex wrote: > > Although using the callback-style APIs might be more common (and in > > some sence nicer, since it allows you to abort the handshake > > a bit earlier -- but an app developer might not care about this very > > much), I think it would be a surprise to most app developers that > > using the get-style APIs might not be secure. > > > > (And I wouldn't be surprised at all if real applications using > > those get() style APIs are found...) >=20 > The get-style API is _the_only_ API that I provide to our applications. > Besides, I'm coming from the GSS-API world, and there never was > a callback API. >=20 > If you think that get-style API is dangerous, then you seem to be > quite unaware about the risks involved with some of the callback APIs > (besides being difficult to use in distributed architectures). I did not intend to imply that callback-style APIs are somehow=20 better; clearly both can have cases where what the app developer expects the library to do could be quite different from what TLS actually does... Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Wed Dec 9 05:48: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 3DCBC3A69F7 for ; Wed, 9 Dec 2009 05:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 MDnbaKSCq7Oy for ; Wed, 9 Dec 2009 05:48:56 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 17D353A6895 for ; Wed, 9 Dec 2009 05:48:55 -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 nB9DfjLP015407; Wed, 9 Dec 2009 15:42:22 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:42:20 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:42:15 +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, 9 Dec 2009 15:42:10 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 9 Dec 2009 14:42:09 +0100 From: To: , Date: Wed, 9 Dec 2009 14:42:08 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp4Xg2Ap/Z/zUyGSRO2VT2liK8slgAdwcxg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D2409D@NOK-EUMSG-01.mgdnok.nokia.com> References: <200912082044.nB8Kifxv006654@fs4113.wdf.sap.corp> <4B1EE0BD.7020403@extendedsubset.com> In-Reply-To: <4B1EE0BD.7020403@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: 09 Dec 2009 13:42:10.0620 (UTC) FILETIME=[6844FFC0:01CA78D5] X-Nokia-AV: Clean Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 09 Dec 2009 13:48:57 -0000 Marsh Ray wrote: > After this fix, the TLS concept of "remote party identity" becomes > maximally "the identity established by the union of all valid and > correct credentials validated during the establishment of a > connection state on this connection, and transitively to all > connections sharing at least one master_secret". If this was what the TLS libraries present to applications in their APIs, all would be fine. But clearly the current APIs lead app developers to expect quite different concept of "remote party identity"... Best regards, Pasi From mrex@sap.com Wed Dec 9 12:21: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 596873A6846 for ; Wed, 9 Dec 2009 12:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 ttxkMMEM+zPB for ; Wed, 9 Dec 2009 12:21: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 EEA913A68DF for ; Wed, 9 Dec 2009 12:21:09 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB9KKvlk013248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Dec 2009 21:20:57 +0100 (MET) From: Martin Rex Message-Id: <200912092020.nB9KKu39003981@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 9 Dec 2009 21:20:56 +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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 09 Dec 2009 20:21:14 -0000 Here is my analysis of the requirements and implementation efforts for TLS extension RI with magic cipher suites value (MCSV), based on my recent experiences from implementing draft-mrex-tls-secure-renegotiation-03 in OpenSSL-0.9.8l and looking at the early implementation of draft-rescorla in the OpenSSL-0.9.8-snapshot. The purpose of the MCSV is: - provide interop with installed base of old, extensions-intolerant servers (original&correct SSLv3 and "defective" TLSv1.0) - provide protection from downgrade attacks (extension-less ClientHello or SSLv2 ClientHello) - provide protection in backwards interop scenarios (renegotiation requested by old servers). in order to reliably provide this, - MCSV is defined to represent an empty TLS extension RI - MSCV MUST be included in *ALL* initial ClientHello handshakes messages _plus_ all renegotiation ClientHellos in backwards interop scenarios (independent of full handshake or session resume). - empty TLS extension RI MUST NOT be sent, ever! - TLS extension RI with Client.Finished.verify_data in ClientHello - MUST NOT be sent on renegotiation handshakes in backward interop scenarios with old servers which could otherwise break - MUST be sent in all other renegotiations If the spec would require that an empty TLS extension RI in a ClientHello MUST be completely ignored, then _everyone_ can save 5-10 LoC. There is a significant difference between extensions-tolerant and extensions-support. Extensions tolerant means, that a server will not choke on a ClientHello handshake message, but instead simply ignore all data following compression methods compliant to the provision in the updated-but-never-published SSLv3, TLSv1.0 and TLSv1.1 specs. In order to implement secure renegotiation with TLS extension RI a "generic" TLS extensions parser (~150 LoC) is necessary to find the TLS extension RI among other extensions, process it and create and process the TLS extension RI reply. Support for other TLS extensions and API-level access to TLS extensions is completely out-of-scope for the following. Adding MCSV to ClientHello on the client and parsing MCSV from the ClientHello on the server will typically be <10 LoC each. Creating an processing an empty TLS extension RI on the ServerHello is also typically <10 LoC each for extension-less implementations. Types of TLS peers in the current installed base: 1.) old TLS client, no extensions, no renegotiation 2.) old TLS client, no extensions, renegotiation 3.) old TLS client, extensions, no renegotiation 4.) old TLS client, extensions, renegotiation 5.) old TLS server, extensions-intolerant, no renegotiation 6.) old TLS server, extensions-intolerant, renegotiation 7.) old TLS server, no extensions, no renegotiation 8.) old TLS server, no extensions, renegotiation 9.) old TLS server, extensions, no renegotiation 10.) old TLS server, extensions, renegotiation The server patches that are currently applied in the field are (6) -> (5) (8) -> (7) (10) -> (9) Additional types of TLS peers when TLS extension RI is implemented: 11.) updated TLS client, RI-minimal, no renegotiation 12.) updated TLS client, RI-only, renegotiation 13.) updated TLS client, extensions, no renegotiation 14.) updated TLS client, extensions, renegotiation 15.) updated TLS server, RI-minimal, no renegotiation 16.) updated TLS server, RI-only, renegotiation 17.) updated TLS server, extensions, no renegotiation 18.) updated TLS server, extensions, renegotiation Effect of requiring MCSV on implementation effort -- for non-renegotiating servers: If we require MSCV on _every_ ClientHello then the update (5),(6),(7),(8) -> (15) amounts to ~20 LoC the update (9),(10) -> (17) amounts to ~40 LoC If we do not require MCSV on _every_ ClientHello then the update (5),(6),(7),(8) -> (15) amounts to ~80 LoC the update (9),(10) -> (17) amounts to ~60 LoC Effect of requiring MCSV on implementation effort -- for non-renegotiating clients: If we require MCSV on _every_ ClientHello, then the update (1),(2) -> (11) amounts to ~20 LoC (3) -> (13) amounts to ~40 LoC If we do not require MCSV on _every_ ClientHello, then the update (1),(2) -> (11) amounts to ~80 LoC (3) -> (13) amounts to ~60 LoC guestimates about secure rengotiation efforts: Servers: these are independent of whether MCSV is required (10) -> (18) maybe ~180 LoC (6),(8) -> (16) maybe ~200 LoC (6),(8) -> (18) maybe ~250 LoC Clients: these are independend of whether MCSV is required. (4) -> (14) maybe ~180 LoC (2) -> (12) maybe ~200 LoC (2) -> (14) maybe ~250 LoC -Martin From marsh@extendedsubset.com Wed Dec 9 13:48: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 A1C3E28C18A for ; Wed, 9 Dec 2009 13:48:19 -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 5ENvXjor3tHe for ; Wed, 9 Dec 2009 13:48: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 3237F28C16B for ; Wed, 9 Dec 2009 13:48:18 -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 1NIUOE-0007xj-OH; Wed, 09 Dec 2009 21:48:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B5957603A; Wed, 9 Dec 2009 21:48: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+EKCeqNDqpjpIpBMzjRlpRMrrisZb42G4= Message-ID: <4B201B0E.2080600@extendedsubset.com> Date: Wed, 09 Dec 2009 15:47:58 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912092020.nB9KKu39003981@fs4113.wdf.sap.corp> In-Reply-To: <200912092020.nB9KKu39003981@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] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 09 Dec 2009 21:48:19 -0000 Martin Rex wrote: > Here is my analysis of the requirements and implementation efforts > for TLS extension RI with magic cipher suites value (MCSV), based on > my recent experiences from implementing > draft-mrex-tls-secure-renegotiation-03 in OpenSSL-0.9.8l and looking > at the early implementation of draft-rescorla in the > OpenSSL-0.9.8-snapshot. > > The purpose of the MCSV is: > > - provide interop with installed base of old, extensions-intolerant > servers (original&correct SSLv3 and "defective" TLSv1.0) The draft-freier-ssl-version3-02.txt says to ignore data after the Client Hello, which implies extension-intolerant SSLv3 servers are defective, too. Not that it really matters at this point. Had you mentioned something about an earlier version not saying that? > - provide protection from downgrade attacks (extension-less > ClientHello or SSLv2 ClientHello) It enables clients which choose to send an SSLv2-compatible Client Hello to do so and indicate support for RI. > - provide protection in backwards interop scenarios (renegotiation > requested by old servers). It will never be safe to conduct renegotiation with a remote party in the absence of negotiated RI. The expectation is that clients and servers will be transitioned into "strict mode" at the earliest opportunity. > in order to reliably provide this, > > - MCSV is defined to represent an empty TLS extension RI > > - MSCV MUST be included in *ALL* initial ClientHello handshakes > messages _plus_ all renegotiation ClientHellos in backwards interop > scenarios (independent of full handshake or session resume). MCSV or an empty RI extension should be sent in > - empty TLS extension RI MUST NOT be sent, ever! No, you just shouldn't send it if you prefer to interop with old, broken servers. Lots of clients (browsers, etc) currently do send extensions on Client Hello, so they may never choose to send MCSV on those connections. It is hoped that at some point in the future, extension-intolerant (and -ignorant) servers will be insignificant and the MCSV can stop being sent by clients. Yes, the MCSV is a work-around for old broken servers. This work-around does not constitute the endorsement of brokenness by anyone. It's simply that in this one bugfix we are choosing to be extra accommodating. > - TLS extension RI with Client.Finished.verify_data in ClientHello - > MUST NOT be sent on renegotiation handshakes in backward interop > scenarios with old servers which could otherwise break They are already broken. It's better to break them in a way that doesn't represent a vulnerability. There's no safe way to renegotiate with a remote party that doesn't properly use RI on all handshakes. To the extent that both parties have an interest in ensuring the connection is secure against MitM attacks, it's not even safe to complete an initial handshake and set up a connection with a remote party that doesn't properly use RI on all handshakes. Realistically, people will need a temporary "compatible mode" in place during deployment of the patch. But you don't gain much actual security in that mode. > - MUST be sent in all other renegotiations All renegotiations. > If the spec would require that an empty TLS extension RI in a > ClientHello MUST be completely ignored, then _everyone_ can save 5-10 > LoC. Why would you want to ignore that a client is attempting to negotiate the use of RI? > There is a significant difference between extensions-tolerant and > extensions-support. Extensions tolerant means, that a server will > not choke on a ClientHello handshake message, but instead simply > ignore all data following compression methods compliant to the > provision in the updated-but-never-published SSLv3, TLSv1.0 and > TLSv1.1 specs. > > In order to implement secure renegotiation with TLS extension RI a > "generic" TLS extensions parser (~150 LoC) is necessary to find the > TLS extension RI among other extensions, process it and create and > process the TLS extension RI reply. Support for other TLS extensions > and API-level access to TLS extensions is completely out-of-scope > for the following. Yep. They have to write a few lines of code to implement a tiny part of the June 2003 RFC 3546 on TLS extensions. > Adding MCSV to ClientHello on the client and parsing MCSV from the > ClientHello on the server will typically be <10 LoC each. > > Creating an processing an empty TLS extension RI on the ServerHello > is also typically <10 LoC each for extension-less implementations. So you're saying that an implementor who has let their code rot for the last 6.5 years could save 140 LoC? Personally, I don't find that to be a primary consideration. > Types of TLS peers in the current installed base: > > 1.) old TLS client, no extensions, no renegotiation * Vulnerable to injection when talking to an unpatched or compatible-mode server which allows renegotiation. * Vulnerable to credential stealing when supplying client auth and routed by the attacker to an unpatched or compatible-mode server which allows renegotiation. > 2.) old TLS client, no extensions, renegotiation * Vulnerable to injection when talking to an unpatched or compatible-mode server which allows renegotiation. * Vulnerable to credential stealing when supplying client auth and routed by the attacker to an unpatched or compatible-mode server which allows renegotiation. * Possibly vulnerable to a client-side renegotiation attack. > 3.) old TLS client, extensions, no renegotiation * Vulnerable to injection when talking to an unpatched or compatible-mode server which allows renegotiation. * Vulnerable to credential stealing when supplying client auth and routed by the attacker to an unpatched or compatible-mode server which allows renegotiation. > 4.) old TLS client, extensions, renegotiation * Vulnerable to injection when talking to an unpatched or compatible-mode server which allows renegotiation. * Vulnerable to credential stealing when supplying client auth and routed by the attacker to an unpatched or compatible-mode server which allows renegotiation. * Possibly vulnerable to a client-side renegotiation attack. > 5.) old TLS server, extensions-intolerant, no renegotiation * Broken according to every spec published in the last 13 years. * Possibly vulnerable to a client-side renegotiation attack. > 6.) old TLS server, extensions-intolerant, renegotiation * Broken according to every spec published in the last 13 years. * Vulnerable to injection when talking to an unpatched or compatible-mode client. * Possibly vulnerable to a client-side renegotiation attack. > 7.) old TLS server, no extensions, no renegotiation * Possibly vulnerable to a client-side renegotiation attack. > 8.) old TLS server, no extensions, renegotiation * Vulnerable to injection when talking to an unpatched or compatible-mode client. * Possibly vulnerable to a client-side renegotiation attack. > 9.) old TLS server, extensions, no renegotiation * Possibly vulnerable to a client-side renegotiation attack. > 10.) old TLS server, extensions, renegotiation * Vulnerable to injection when talking to an unpatched or compatible-mode client. * Possibly vulnerable to a client-side renegotiation attack. > The server patches that are currently applied in the field are (6) -> > (5) (8) -> (7) (10) -> (9) Reasonable to assume. > Additional types of TLS peers when TLS extension RI is implemented: > > 11.) updated TLS client, RI-minimal, no renegotiation Could you explain what you mean by RI-minimal, RI-only, and "extensions". > 12.) updated TLS client, RI-only, renegotiation > 13.) updated TLS client, extensions, no renegotiation > > 14.) updated TLS client, extensions, renegotiation > > 15.) updated TLS server, RI-minimal, no renegotiation > > 16.) updated TLS server, RI-only, renegotiation > > 17.) updated TLS server, extensions, no renegotiation > > 18.) updated TLS server, extensions, renegotiation > > > > Effect of requiring MCSV on implementation effort -- for > non-renegotiating servers: > > If we require MSCV on _every_ ClientHello then the update > (5),(6),(7),(8) -> (15) amounts to ~20 LoC the update (9),(10) > -> (17) amounts to ~40 LoC > > If we do not require MCSV on _every_ ClientHello then the update > (5),(6),(7),(8) -> (15) amounts to ~80 LoC the update (9),(10) > -> (17) amounts to ~60 LoC > Effect of requiring MCSV on implementation effort -- for > non-renegotiating clients: > > If we require MCSV on _every_ ClientHello, then the update (1),(2) -> > (11) amounts to ~20 LoC (3) -> (13) amounts to ~40 LoC > > If we do not require MCSV on _every_ ClientHello, then the update > (1),(2) -> (11) amounts to ~80 LoC (3) -> (13) amounts to ~60 LoC Those tiny LoC differences are not significant, especially considering the margin of error for those types of things. Usually you're lucky to get within a factor of two. They certainly don't give a realistic indication of "level of effort". > guestimates about secure rengotiation efforts: > > Servers: these are independent of whether MCSV is required (10) -> > (18) maybe ~180 LoC (6),(8) -> (16) maybe ~200 LoC (6),(8) -> > (18) maybe ~250 LoC > > Clients: these are independend of whether MCSV is required. (4) -> > (14) maybe ~180 LoC (2) -> (12) maybe ~200 LoC (2) -> (14) maybe > ~250 LoC I think the conclusion that we can draw from those numbers is that it's more code than fixing a missing semicolon, and less code than a medium-sized coding project. Looks pretty reasonable for a bug fix to me. Looks like a lucky break considering the depth at which the problem lies. Thanks for working out all those estimates. - Marsh From marsh@extendedsubset.com Wed Dec 9 14:59: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 165763A67EB for ; Wed, 9 Dec 2009 14:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: 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-gzSHAfl82 for ; Wed, 9 Dec 2009 14:59:40 -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 3296C3A680F for ; Wed, 9 Dec 2009 14:59:40 -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 1NIVVI-000MvP-NQ; Wed, 09 Dec 2009 22:59:28 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7FDAE603A; Wed, 9 Dec 2009 22:59: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/ABt8eWND4kJvse0b5O6HiEvyk62XZH54= Message-ID: <4B202BCD.40500@extendedsubset.com> Date: Wed, 09 Dec 2009 16:59:25 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@cs.tcd.ie> <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E786A.7070100@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31D2391E@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 09 Dec 2009 22:59:41 -0000 Hello all, I'm wearing a warm red and gray hat today. Pasi.Eronen@nokia.com wrote: > Marsh Ray wrote: > >>> and can cause security vulnerabilities for some of them. >> Do we know of any examples? I can only think of some very subtle and >> hypothetical ones that require client and server apps that are already >> coded for switching identities intentionally. > [...] > > I guess an even worse example would be something like this: > > conn = openTlsConnection(host, port) > if not verifyCertChain(conn.getPeerCert()): > raise "Not a valid cert" > if conn.getPeerCert().getName() != expected_name: > raise "Name in certificate doesn't match" > # continue... _After_ renegotation is fixed (and/or disabled by default) though, how is this a problem? RI proves the data has come from the same remote endpoint. That same remote endpoint has proven that he can supply an acceptable cert, too. In order for this example to be a problem, the legitimate client would have to renegotiate specifically for the purpose of dropping certain cert credentials. This would seem to imply that the application code was expecting cert changes. This is not to say that there's no application that could be confused by such a change, only that I haven't seen any real examples. Nelson suggested a test tool used internally with NSS might do something agressive with certs and renegotiation like that. I don't think it's inherently broken. It seems reasonable to me for one party to say "By the initial handshake and two subsequent renegotiations I have proven posession of the private keys for these three certificates". With renegotiation fixed, credentials supplied on different handshakes may legitimately be treated as additive. This is how https client certificates often work: an initial anon-client connection adds a client cert to the connection by renegotiating. The actual credentials policy should be documented as part of the app protocol on top of TLS. Most of them would document "no renegotiation" and I think that should be the default for implementations. > Most TLS libraries seem to support both callback and get() style > functions for accessing/checking certificates. Most script-language bindings to OpenSSL seem not to support the callback mechanism very well. Just a data point. > Although using the callback-style APIs might be more common (and in > some sence nicer, since it allows you to abort the handshake > a bit earlier -- but an app developer might not care about this very > much), I think it would be a surprise to most app developers that > using the get-style APIs might not be secure. > > (And I wouldn't be surprised at all if real applications using > those get() style APIs are found...) You know they exist when all example code for some very popular implementations and languages does it that way. - Marsh From mrex@sap.com Wed Dec 9 15:09: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 5A69A3A67C1 for ; Wed, 9 Dec 2009 15:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 77XiiYbCF68i for ; Wed, 9 Dec 2009 15:09: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 B2EB43A672E for ; Wed, 9 Dec 2009 15:09:31 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nB9N9Hb3026241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 00:09:17 +0100 (MET) From: Martin Rex Message-Id: <200912092309.nB9N9G0r014068@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 10 Dec 2009 00:09:16 +0100 (MET) In-Reply-To: <4B201B0E.2080600@extendedsubset.com> from "Marsh Ray" at Dec 9, 9 03:47: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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 09 Dec 2009 23:09:33 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Here is my analysis of the requirements and implementation efforts > > for TLS extension RI with magic cipher suites value (MCSV), based on > > my recent experiences from implementing > > draft-mrex-tls-secure-renegotiation-03 in OpenSSL-0.9.8l and looking > > at the early implementation of draft-rescorla in the > > OpenSSL-0.9.8-snapshot. > > > > The purpose of the MCSV is: > > > > - provide interop with installed base of old, extensions-intolerant > > servers (original&correct SSLv3 and "defective" TLSv1.0) > > The draft-freier-ssl-version3-02.txt says to ignore data after the > Client Hello, which implies extension-intolerant SSLv3 servers are > defective, too. Not that it really matters at this point. Had you > mentioned something about an earlier version not saying that? The official SSLv3 spec doesn't say that! The IETF archives do not know freier-ssl-version3-02 (only -00 and -01) freier-ssl-version3-02 is probably what is known as draft-ietf-tls-ssl-version3-00.txt -- a document which the TLS WG chose _NOT_ to publish as informational, and which Netscape did _NOT_ see as an official spec, otherwise they would have updated their much more prominently offered versions of the SSLv3 spec based on the freier -01 draft _without_ the extensibility option. > > > - provide protection in backwards interop scenarios (renegotiation > > requested by old servers). > > It will never be safe to conduct renegotiation with a remote party in > the absence of negotiated RI. That is wrong. An old server (potentially an extensions-intolerant one) does only mean that renegotiation with _that_ old server will remain unprotected. What secure TLS renegotiation should protect from is a downgrade attack, that an MitM acts as an old extensions-intolerant server and then proxies an updated clients renegotiation with an presumably old server into the handshake of a backwards-compatible updated server. Only MCSV can provide this protection. TLS extension RI on renegotiation will break interop with all old servers that request renegotiation. > > The expectation is that clients and servers will be transitioned into > "strict mode" at the earliest opportunity. You seem to entirely ignore the transition period. We can not shut down the entire internet, wait for 6 or 12 months until everybody has updated every client and server, and then re-launch the internet. If we do not provide provisions for smooth interop for at least the transition period, it will hurt _everyone_! Users and admins will _not_ install client-side patches if these are disruptive to some usage scenarios (it's mostly a server problem). And when clients are not updated, then Server operators that need that functionality and do not want to loose significant sales can not disable old renegotiations on their servers. > > > - empty TLS extension RI MUST NOT be sent, ever! > > No, you just shouldn't send it if you prefer to interop with old, broken > servers. Lots of clients (browsers, etc) currently do send extensions on > Client Hello, so they may never choose to send MCSV on those connections. Several hundred millions clients do _not_ send extensions on ClientHello. > > It is hoped that at some point in the future, extension-intolerant (and > -ignorant) servers will be insignificant and the MCSV can stop being > sent by clients. 5-10 years. > > Yes, the MCSV is a work-around for old broken servers. This work-around > does not constitute the endorsement of brokenness by anyone. It's simply > that in this one bugfix we are choosing to be extra accommodating. No, MCSV is _not_ only a necessesity for a few broken TLSv1.0 servers, it is also a necessity for a number of fully compliant SSLv3 servers _and_ it is an enabler to _relief_ old servers (including extensions-tolerant) from having to add 5x the amount of code to their code base which has nothing to do with the underlying security problem. > > > - TLS extension RI with Client.Finished.verify_data in ClientHello - > > MUST NOT be sent on renegotiation handshakes in backward interop > > scenarios with old servers which could otherwise break > > They are already broken. It's better to break them in a way that doesn't > represent a vulnerability. The client can easily abort when it doesn't like the server's answer, so there is absolutely _no_ justification for the client to send data that will cause interop problems. For an updated server in an MitM attack scenario, the presence of the MCSV is sufficient to realize that it is talking to an updated client that is probing. > > There's no safe way to renegotiate with a remote party that doesn't > properly use RI on all handshakes. You're confused. This requirement is about protection from MitM-attacks, it is _NOT_ about successful secure renegotiations (which are not possible when talking to an old server in backwards interop mode). > > > - MUST be sent in all other renegotiations > > All renegotiations. > > > If the spec would require that an empty TLS extension RI in a > > ClientHello MUST be completely ignored, then _everyone_ can save 5-10 > > LoC. > > Why would you want to ignore that a client is attempting to negotiate > the use of RI? Simple answer: to facilitate testing and QA. Make sure that every client is correctly sending MCSV. We do not need two signaling mechanisms where one is perfectly sufficient. Besides, MCSV is 3-5 octets less on the wire and you need the code for MCSV anyway-- so the most reasonable solution is to make it mandatory to use. > > Yep. They have to write a few lines of code to implement a tiny part of > the June 2003 RFC 3546 on TLS extensions. > > > Adding MCSV to ClientHello on the client and parsing MCSV from the > > ClientHello on the server will typically be <10 LoC each. > > > > Creating an processing an empty TLS extension RI on the ServerHello > > is also typically <10 LoC each for extension-less implementations. > > So you're saying that an implementor who has let their code rot for the > last 6.5 years could save 140 LoC? > > Personally, I don't find that to be a primary consideration. Rot for 6.5 years? What are you talking about? There is even brand new code under active maintenance without support for TLS extensions. TLS extensions is purely optional, not part of the vulnerability and does not need to be part of the solution. Besides, in those cases where it is about code that has been mostly unchanged for 6+ years, it is not "implementers" who will have to add the secure renegotiation patch, it will often be "maintainers" with little knowledge about the code -- and then, it makes perfect sense to ask them for only 20 lines of code instead of 150+ > > > Additional types of TLS peers when TLS extension RI is implemented: > > > > 11.) updated TLS client, RI-minimal, no renegotiation > > Could you explain what you mean by RI-minimal, RI-only, and "extensions". RI-minimal client (one which does not implement renegotiation): sends MCSV on ClientHello, tolerates ServerHellos with extra data following compression-method, i.e. will complete handshake if that extra data is 7 octets long and resembles an empty extension RI 0x00 0x05 0xFF 0x01 0x00 0x01 0x00 and abort the handshake otherwise. RI-minimal server (one which does not implement renegotiation): searches MCSV in ClientHello, ignores TLS extensions completely sends back the above 7 octets extra data after compression_method in ServerHello when MCSV was found. RI-only client (one which does not implement TLS extensions in general but adds secure renegotiation with TLS extension RI): minimalistic TLS extensions support, only for TLS extension RI, sends MCSV in initial ClientHellos, sends TLS extension RI with Client.Finished.verify_data on renegotiation can parse TLS extension RI in ServerHello, and in order to reliably recognize updated Servers on renegotiation, it must be able to find TLS extension RI among other ServerHello extensions (or abort if there are others) RI-only server (one which does not implemet TLS extensions in general but adds secure renegotiation with TLS extension RI): minimalistic TLS extensions support, only for TLS extension RI, can find and parse TLS extension RI in ClientHello between other extensions, will send back fixed 7-octet string above on initial handshakes and TLS extension RI with content on renegotiation handshakes when the ClientHello contains MCSV or TLS extension RI. > > Those tiny LoC differences are not significant, especially considering > the margin of error for those types of things. Usually you're lucky to > get within a factor of two. 20 LoC vs. 80 LoC can be a HUGE difference for old code that one doesn't know. ~20 LoC is 1 day implementing, 1 day testing. ~80 LoC is 3 day implementing, 5 day testing. > > They certainly don't give a realistic indication of "level of effort". I've been doing development, support, maintenance and QA for mission critical software for the past 14 year, and I can assure you, they do give a pretty good picture about the effort. If you're providing free and open source software, you might not worry about trial-and-error. If you are a software vendor that charges for maintenance, then it is a completely different issue. You do not change any code that has been in extended maintenance mode for a few years, and the original authors of that code are likely not the ones who will have to patch the code. There are software logistic procedures in place that make it extremely expensive and extremely unlikely that you make code changes that break interoperability "unintentionally". Have you worked for a software company with 5000+ software developers during the last three years? -Martin From mrex@sap.com Wed Dec 9 16:04: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 F104328C140 for ; Wed, 9 Dec 2009 16:04:45 -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 ydOtDP1eig-H for ; Wed, 9 Dec 2009 16:04: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 4B54C3A6A9E for ; Wed, 9 Dec 2009 16:04:42 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBA04SCP018067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 01:04:28 +0100 (MET) From: Martin Rex Message-Id: <200912100004.nBA04REb017724@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 10 Dec 2009 01:04:27 +0100 (MET) In-Reply-To: <4B202BCD.40500@extendedsubset.com> from "Marsh Ray" at Dec 9, 9 04:59: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: Re: [TLS] Summarizing identity change discussion so far 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, 10 Dec 2009 00:04:46 -0000 Marsh Ray wrote: > > > I guess an even worse example would be something like this: > > > > conn = openTlsConnection(host, port) > > if not verifyCertChain(conn.getPeerCert()): > > raise "Not a valid cert" > > if conn.getPeerCert().getName() != expected_name: > > raise "Name in certificate doesn't match" > > # continue... > > _After_ renegotation is fixed (and/or disabled by default) though, how > is this a problem? RI proves the data has come from the same remote > endpoint. That same remote endpoint has proven that he can supply an > acceptable cert, too. > > In order for this example to be a problem, the legitimate client would > have to renegotiate specifically for the purpose of dropping certain > cert credentials. This would seem to imply that the application code was > expecting cert changes. The above code sample provide by Pasi is about client-side code, as indicated by "openTlsConnection" and the comparison "conn.getPeerCert().getName() != expected_name" So this is more about server certificates changing then clients using different credentials. And it is about apps coding above TLS, and not about details of TLS implementations. Since a non-negligible amount of clients will need allow old renegotiation for a little while, one might want to think about mitigating unexpected changes the server certificate. > > This is not to say that there's no application that could be confused by > such a change, only that I haven't seen any real examples. Nelson > suggested a test tool used internally with NSS might do something > agressive with certs and renegotiation like that. > > I don't think it's inherently broken. It seems reasonable to me for one > party to say "By the initial handshake and two subsequent renegotiations > I have proven posession of the private keys for these three certificates". There are a lot of applications scenarios where this either doesn't make any sense or will cause endless problems, support calls and confusion. Would you want your browser to send *ALL* your WWW-authenticate credentials to every server and let the server pick (AFAIK the protocol doesn't even allow that). In most Audit log facilities, you can only log *ONE* identity for which an operation was attempted (and failed or succeeded), and not an arbitrary set of identites. As soon as you have larger distributed systems, your TLS endpoint might be a reverse proxy at the perimeter of the backend server farm. The reverse proxy is going to forward the initially authenticated cert to the backend application, the backend application will perform an authentication, create a backend session and issue a session identifier. >From that point on, all requests carrying that session ID will be processed under this backend session context, and the reverse proxy will often forward all requests with that session identifier to the same backend host (because of the backend state identified by the session id). To the backend server, it is entirely irrelevant how many TCP connections there are established between a client and the revers proxy -- and for protocols like HTTPS, these will be terminated quite often. For HTTPS, a client that shows a different cert after renegotiation just doesn't make any sense most of the time. If the client wants to use a different cert, he should open a new network connection. If the reverse proxy or the backend wants to mitigate session-id-stealing it might employ a memcmp() on the certificates forwarded by the reverse proxy, and will rightfully abort if that changes. A client architecture which allows the use of different client certificates on different connects and does not reliably distinguish TLS sessions established with different client properties (anonymous, client cert A, client cert B, ...) is probably broken. > > With renegotiation fixed, credentials supplied on different handshakes > may legitimately be treated as additive. This is how https client > certificates often work: an initial anon-client connection adds a client > cert to the connection by renegotiating. Nope, that is not how it works. A client that has not been previously authenticated performs a client cert authentication. That is a highlander operation. Which of the TLS implementation actually keeps a set of certs/cert-chains for a TLS peer crowd created through renegotiation and has API calls to iterate through them? The implementations that I know have only APIs to request "THE" peer certificate. So if there actually are apps today that can handle a multitude of client identites on a SSL/SecurityContext handle, they will likely have to implement that at the app layer, because very few, if any TLS implementations provide "a set of TLS peers". -Martin From mrex@sap.com Wed Dec 9 16:18: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 7C7103A68C1 for ; Wed, 9 Dec 2009 16:18:52 -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 grv32i6bjntx for ; Wed, 9 Dec 2009 16:18:51 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5FE573A684F for ; Wed, 9 Dec 2009 16:18:51 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBA0Ia1F010514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 01:18:36 +0100 (MET) From: Martin Rex Message-Id: <200912100018.nBA0IZN8018573@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 10 Dec 2009 01:18:34 +0100 (MET) In-Reply-To: <4B201B0E.2080600@extendedsubset.com> from "Marsh Ray" at Dec 9, 9 03:47: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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 10 Dec 2009 00:18:52 -0000 Marsh Ray wrote: > > > The purpose of the MCSV is: > > > > - provide interop with installed base of old, extensions-intolerant > > servers (original&correct SSLv3 and "defective" TLSv1.0) > > > > - provide protection from downgrade attacks (extension-less > > ClientHello or SSLv2 ClientHello) > > > > - provide protection in backwards interop scenarios (renegotiation > > requested by old servers). > > It will never be safe to conduct renegotiation with a remote party in > the absence of negotiated RI. As I wrote a while ago, the name "TLS_RENEGO_PROTECTION_REQUEST" was chosen _not_ as a requst for secure renegotiation (which it is NOT), but as a request for _protection_ from the vulnerability through old TLS renegotiation. There are two different issues that the fix needs to provide: - secure renegotiation between updated clients and servers directly talking to each other - protection from MitM attacks in all 3 attack scenarios - protection from MitM attacks for communication between updated clients and updated servers even when both allow old renegotiation for backwards interop. The secure renegotiation is provided by "authenticating" the verify data from the previous finished messages. TLS extension RI performs the authentication with memcmp() on data exchanged through a TLS extension in the renegotiation handshake. The protection is provided through negotiating/signaling with the peer that one is updated. TLS extension RI does both with the same piece of data in the handshake message (TLS extension RI), and it seems that some people fail to understand the difference between the two things. Previously, I wrote that draft-mrex-tls-secure-renegotiation-03.txt is a "nanny spec", because it does _not_only_ describes how to perform secure renegotiation, but it _also_ describes how to implement backwards interop securely. This discussion here sugggests that this difference is unclear to at least some people, and therefore should be better explained in the draft-ietf-tls-renegotiation-02 as well! -Martin From mickgray@au1.ibm.com Wed Dec 9 18:18: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 968A43A69FA for ; Wed, 9 Dec 2009 18:18:42 -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 RPbFUJvGsq7f for ; Wed, 9 Dec 2009 18:18:41 -0800 (PST) Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by core3.amsl.com (Postfix) with ESMTP id B84933A68EA for ; Wed, 9 Dec 2009 18:18:40 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBA2IKY6015034 for ; Thu, 10 Dec 2009 13:18:20 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBA2EbQd1630218 for ; Thu, 10 Dec 2009 13:14:38 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBA2IR1n004126 for ; Thu, 10 Dec 2009 13:18:27 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBA2IRo1004120 for ; Thu, 10 Dec 2009 13:18:27 +1100 In-Reply-To: <200912092020.nB9KKu39003981@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Thu, 10 Dec 2009 12:16:24 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 10/12/2009 13:25:26 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 02:18:42 -0000 mrex@sap.com wrote: > Here is my analysis of the requirements and implementation efforts > for TLS extension RI with magic cipher suites value (MCSV), based on my > recent experiences from implementing draft-mrex-tls-secure-renegotiation-03 > in OpenSSL-0.9.8l and looking at the early implementation of draft-rescorla > in the OpenSSL-0.9.8-snapshot. > > The purpose of the MCSV is: > > - provide interop with installed base of old, extensions-intolerant > servers (original&correct SSLv3 and "defective" TLSv1.0) > > - provide protection from downgrade attacks > (extension-less ClientHello or SSLv2 ClientHello) > > - provide protection in backwards interop scenarios > (renegotiation requested by old servers). > > > in order to reliably provide this, > > - MCSV is defined to represent an empty TLS extension RI > > - MSCV MUST be included in *ALL* initial ClientHello handshakes > messages _plus_ all renegotiation ClientHellos in backwards > interop scenarios (independent of full handshake or session resume). > > - empty TLS extension RI MUST NOT be sent, ever! This looks good to me, the only thing I would change is I think MUST NOT would be better as SHOULD NOT as the later requires that the implementer examine the conditions and implications etc to make the best decision. We know that many current browsers always send extensions and for that use case there is no need to change due to this specification. However we also know that there is a large installed base of SSL consuming applications that are not browser related that have never had any requirement process extensions and therefore do not support extensions or are extension intolerant. > - TLS extension RI with Client.Finished.verify_data in ClientHello > - MUST NOT be sent on renegotiation handshakes in backward > interop scenarios with old servers which could otherwise break > - MUST be sent in all other renegotiations > > > If the spec would require that an empty TLS extension RI in a > ClientHello MUST be completely ignored, then _everyone_ can save 5-10 LoC. > > There is a significant difference between extensions-tolerant and > extensions-support. Extensions tolerant means, that a server > will not choke on a ClientHello handshake message, but instead > simply ignore all data following compression methods compliant > to the provision in the updated-but-never-published SSLv3, > TLSv1.0 and TLSv1.1 specs. > > In order to implement secure renegotiation with TLS extension RI > a "generic" TLS extensions parser (~150 LoC) is necessary to > find the TLS extension RI among other extensions, process it > and create and process the TLS extension RI reply. We used 177 LoC for a generic parser and another 106 LoC for the RI specific logic. However our experience is that additional effort to back port into unfamiliar old code is far more costly in time than one would expect based on LoC count even when considering we have current code that supports extensions. Additionally a large problem is testing this in code bases that do not support extensions. Manual testing can be done, but that is prone to error, is costly, and time consuming each time we release code, which means we will need to spend a lot more time developing automated testing. > Support > for other TLS extensions and API-level access to TLS extensions > is completely out-of-scope for the following. Agree > > > Adding MCSV to ClientHello on the client and parsing MCSV from > the ClientHello on the server will typically be <10 LoC each. Agree > > Creating an processing an empty TLS extension RI on the ServerHello > is also typically <10 LoC each for extension-less implementations. > > > Types of TLS peers in the current installed base: > > 1.) old TLS client, no extensions, no renegotiation > > 2.) old TLS client, no extensions, renegotiation > > 3.) old TLS client, extensions, no renegotiation > > 4.) old TLS client, extensions, renegotiation > > > 5.) old TLS server, extensions-intolerant, no renegotiation > > 6.) old TLS server, extensions-intolerant, renegotiation > > 7.) old TLS server, no extensions, no renegotiation > > 8.) old TLS server, no extensions, renegotiation > > 9.) old TLS server, extensions, no renegotiation > > 10.) old TLS server, extensions, renegotiation > > > The server patches that are currently applied in the field are > (6) -> (5) > (8) -> (7) > (10) -> (9) > > > Additional types of TLS peers when TLS extension RI is implemented: > > 11.) updated TLS client, RI-minimal, no renegotiation > > 12.) updated TLS client, RI-only, renegotiation > > 13.) updated TLS client, extensions, no renegotiation > > 14.) updated TLS client, extensions, renegotiation > > > 15.) updated TLS server, RI-minimal, no renegotiation > > 16.) updated TLS server, RI-only, renegotiation > > 17.) updated TLS server, extensions, no renegotiation > > 18.) updated TLS server, extensions, renegotiation > > > > Effect of requiring MCSV on implementation effort > -- for non-renegotiating servers: > > If we require MSCV on _every_ ClientHello > then the update (5),(6),(7),(8) -> (15) amounts to ~20 LoC > the update (9),(10) -> (17) amounts to ~40 LoC > > If we do not require MCSV on _every_ ClientHello > then the update (5),(6),(7),(8) -> (15) amounts to ~80 LoC > the update (9),(10) -> (17) amounts to ~60 LoC > > > Effect of requiring MCSV on implementation effort > -- for non-renegotiating clients: > > If we require MCSV on _every_ ClientHello, > then the update (1),(2) -> (11) amounts to ~20 LoC > (3) -> (13) amounts to ~40 LoC > > If we do not require MCSV on _every_ ClientHello, > then the update (1),(2) -> (11) amounts to ~80 LoC > (3) -> (13) amounts to ~60 LoC > These are very good numbers and closely match an internal analysis I have made. It is likely there will be Servers in critical production environments that can not be patched (e.g. vendor no longer in business) and they will have to be fully replaced, as time, planning and evaluation allows (as I noted here : http://www.imc.org/ietf-tls/mail-archive/msg11082.html) I think the fact that Clients may concurrently interact with Servers of types 5 to 10, means that the MCSV ONLY proposal is the best solution for a low risk deployment. > > > guestimates about secure rengotiation efforts: > > Servers: these are independent of whether MCSV is required > (10) -> (18) maybe ~180 LoC > (6),(8) -> (16) maybe ~200 LoC > (6),(8) -> (18) maybe ~250 LoC > > Clients: these are independend of whether MCSV is required. > (4) -> (14) maybe ~180 LoC > (2) -> (12) maybe ~200 LoC > (2) -> (14) maybe ~250 LoC > My guess is that at least five times the effort will be required to add testing of this into existing auto test harnesses for code levels that do not support extensions. Interestingly this vulnerability fix is the only reason these old code levels now need to support extensions. Given this large test impact I find the draft-mrex-tls-secure-renegotiation-03 alternate solution (which does not require full extension implementation) to be preferable. - Mick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Thu Dec 10 00: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 1A5AE3A693D for ; Thu, 10 Dec 2009 00:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6Chsr5l8+DG for ; Thu, 10 Dec 2009 00:05:09 -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 E2D783A62C1 for ; Thu, 10 Dec 2009 00:05:08 -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 1NIe1B-000BMi-4K; Thu, 10 Dec 2009 08:04:57 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D6234603A; Thu, 10 Dec 2009 08:04: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: U2FsdGVkX186xS261ocV5XLSK0XVdi1lbBzGMO8YjuY= Message-ID: <4B20ABA4.3050805@extendedsubset.com> Date: Thu, 10 Dec 2009 02:04:52 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912092309.nB9N9G0r014068@fs4113.wdf.sap.corp> In-Reply-To: <200912092309.nB9N9G0r014068@fs4113.wdf.sap.corp> 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] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 08:05:12 -0000 Replies to three emails in one. Apologies in advance if this doesn't all get quoted perfectly. Martin Rex wrote: > Marsh Ray wrote: >> The draft-freier-ssl-version3-02.txt says to ignore data after the >> Client Hello, which implies extension-intolerant SSLv3 servers are >> defective, too. Not that it really matters at this point. Had you >> mentioned something about an earlier version not saying that? > > The official SSLv3 spec doesn't say that! > > The IETF archives do not know freier-ssl-version3-02 (only -00 and > -01) freier-ssl-version3-02 is probably what is known as > draft-ietf-tls-ssl-version3-00.txt -- a document which the TLS WG > chose _NOT_ to publish as informational, and which Netscape did _NOT_ > see as an official spec, otherwise they would have updated their much > more prominently offered versions of the SSLv3 spec based on the > freier -01 draft _without_ the extensibility option. That is interesting information. Would you happen to have a copy of the last "official" spec you can send me? I probably got draft-freier-ssl-version3-02.txt from: http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt I don't know if that implies anything "official" past or present. The IETF's DNS seems to be inoperative, but Google has a cached version of: http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 It has the same "it is permitted for a client hello message to include extra data after the compression methods" language. >> It will never be safe to conduct renegotiation with a remote party >> in the absence of negotiated RI. > > That is wrong. An old server (potentially an extensions-intolerant > one) does only mean that renegotiation with _that_ old server will > remain unprotected. And clients that care about the security of the connection had better refuse to connect to it at all! Servers receiving an initial connection request without a request for RI will soon know some things: 1. The client software is not patched for security. 2. There's a good chance the client is vulnerable to one or more variants of this basic attack. Clients receiving a request for renegotiation without having previously negotiated RI can expect that the server is vulnerable to MitM and they may have already been pwned on this connection state. Servers receiving a client-initiated renegotiation without having previously negotiated RI can not know that it is the same party they have on the current connection state. Sure you can point to some combinations of (client renegotiates)x(server renegotiates)x(specific protocol)x(specific implementation) that is not vulnerable, but a fundamental guarantee of TLS is missing and most setups are vulnerable to one or more attacks. Mix in the possibility of application data between the handshake messages and it's just plain not there. Starting soon, the absence of RI on a hello is going to be an increasingly strong indicator of "broken and insecure". Eventually, it will just be discarded along with SSLv1 and v2. > What secure TLS renegotiation should protect from is a downgrade > attack, that an MitM acts as an old extensions-intolerant server and > then proxies an updated clients renegotiation with an presumably old > server into the handshake of a backwards-compatible updated server. This is only a problem while you run in compatible mode. > Only MCSV can provide this protection. I'm missing something. How can MCSV fix "updated clients renegotiation with an presumably old server"? > TLS extension RI on renegotiation will break interop with all old > servers that request renegotiation. That's the least of your problems as a client. Your connection may have already been pwned. Before the renegotiation, you could have held out some hope that the server would never renegotiate at all. But now that you know the server does renegotiation it's like realizing that you've just sent your online banking credentials to an unmaintained Debian Etch system. How could one conduct a secure renegotiation without first establishing that the initial negotiation was secure? The server has an unknown amount of evil buffered state and may be just waiting for you to supply the credentials to act on it. >> The expectation is that clients and servers will be transitioned >> into "strict mode" at the earliest opportunity. > > You seem to entirely ignore the transition period. We can not shut > down the entire internet, wait for 6 or 12 months until everybody has > updated every client and server, and then re-launch the internet. Oh no, we mustn't shut down the entire internet! > If we do not provide provisions for smooth interop for at least the > transition period, it will hurt _everyone_! If you really want to renegotiate with old, broken, unpatched, and extension-intolerant servers so badly that you're willing to do it insecurely then don't send them the freaking extension! Sending them an MCSV is at best going to be ignored by such a server, no matter what semantics some document attaches to it. Just don't expect an IETF I-D in 2010 to magically make something secure that's been nominally obsolete since January 1999 (RFC 2246 TLS 1.0) without having to add more than 20 lines of code! > Users and admins will _not_ install client-side patches if these are > disruptive to some usage scenarios (it's mostly a server problem). > And when clients are not updated, then Server operators that need > that functionality and do not want to loose significant sales can not > disable old renegotiations on their servers. +10 >> Lots of clients (browsers, etc) currently do send extensions on >> Client Hello, so they may never choose to send MCSV on those >> connections. > > Several hundred millions clients do _not_ send extensions on > ClientHello. Not relevant. What matters is the number of servers that hang in a slow fail condition when sent an extension. >> It is hoped that at some point in the future, extension-intolerant >> (and -ignorant) servers will be insignificant and the MCSV can stop >> being sent by clients. > > 5-10 years. I intend to still be capturing packets at that time. >> Yes, the MCSV is a work-around for old broken servers. This >> work-around does not constitute the endorsement of brokenness by >> anyone. It's simply that in this one bugfix we are choosing to be >> extra accommodating. > > No, MCSV is _not_ only a necessesity for a few broken TLSv1.0 > servers, it is also a necessity for a number of fully compliant SSLv3 > servers I believe you, but I can't find a copy of this SSLv3 spec anywhere on the web. However, I don't think there are many on this list who place much weight on the compliance to a spec that appears to have been abandoned 11 years ago. What matters is what's in the field at this point. > _and_ it is an enabler to _relief_ old servers (including > extensions-tolerant) from having to add 5x the amount of code to > their code base which has nothing to do with the underlying security > problem. Look, SSLv3 is broken. Everyone here did their best, but no one could come up with a palatable solution that did not require the use of a protocol extension, even if just for the S->C signaling. Therefore, SSLv3 needs to either be completely deprecated or it needs to have added minimal support for this one extension. Vendors can choose to fix their old SSLv3 implementations if they want to. There are real concessions to interoperability in the proposals. But the fact that the fix to this long-abandoned protocol spec might take 100 lines of code instead of 20 is not going to drive the design. > The client can easily abort when it doesn't like the server's answer, > And it must if it needs proper SSL/TLS security. > so there is absolutely _no_ justification for the client to send data > that will cause interop problems. Sure there is: some clients get a positive benefit from the use of extensions. How to manage the tradeoff between that benefit vs. potential interactions with intolerant servers is something app developers and admins/users currently manage. > For an updated server in an MitM attack scenario, the presence of the > MCSV is sufficient to realize that it is talking to an updated client > that is probing. Right. After that initial Client Hello with the MCSV, the server knows that the client is patched and responds with an extension. From that point on, the client knows he can send extensions. And both endpoints now must send the extension on every single hello on that connection, because they will have nonempty verify_data. > You're confused. Wouldn't be the first time. > This requirement is about protection from MitM-attacks, it is _NOT_ > about successful secure renegotiations (which are not possible when > talking to an old server in backwards interop mode). Sorry, which requirement was that? Again, full protection from these attacks (i.e. effective TLS) involves refusing to handshake with an unpatched remote. >> Why would you want to ignore that a client is attempting to >> negotiate the use of RI? > > Simple answer: to facilitate testing and QA. Make sure that every > client is correctly sending MCSV. Or the RI extension. > We do not need two signaling mechanisms where one is perfectly > sufficient. I don't think one is perfectly sufficient. Keep in mind the attacker generally gets to choose which handshake is presented where. If you allow conformant servers to not look for and validate the RI extension on every single Client Hello they receive, it makes it possible for a patched client's renegotiation handshake to be presented to a patched server which doesn't validate it. So MCSV only needs to be sent on the initial Client Hello, and then only if you aren't sending extensions for any other reason and don't want to upset an unpatched extensions-intolerant server. The client must then validate the emptiness of the RI returned on the Server Hello. Patched clients and servers must validate the content of the (now required to be present and nonempty) RI extension received on subsequent Hellos. The MCSV field on subsequent Client Hellos is now redundant in all cases (both valid and attack). You can save three octets by not sending the MCSV when you're also sending the RI extension. > Besides, MCSV is 3-5 octets less on the wire and you need the code > for MCSV anyway-- so the most reasonable solution is to make it > mandatory to use. That's a pretty weak argument, I know because I'm usually the one making it. I'll take the cost of five extra octets over a phony cipher suite hack any day. >> So you're saying that an implementor who has let their code rot for >> the last 6.5 years could save 140 LoC? >> >> Personally, I don't find that to be a primary consideration. > > Rot for 6.5 years? What are you talking about? RFC 3546 TLS Extensions June 2003 > There is even brand new code under active maintenance without support > for TLS extensions. Well, guess what! The protocol now needs to be extended. > TLS extensions is purely optional, not s/is/were/ > part of the vulnerability and does not need to be part of the > solution. No one came up with any other less-impactful way to do the required S->C signaling, and not for lack of trying. > Besides, in those cases where it is about code that has been mostly > unchanged for 6+ years, it is not "implementers" who will have to add > the secure renegotiation patch, it will often be "maintainers" with > little knowledge about the code -- and then, it makes perfect sense > to ask them for only 20 lines of code instead of 150+ There's no 20 line fix for this. Neither is there a (palatable) solution which does not use extensions. Last I checked, draft-mrex-tls-secure-renegotiation used an extension. >>> 11.) updated TLS client, RI-minimal, no renegotiation >> Could you explain what you mean by RI-minimal, RI-only, and >> "extensions". > > RI-minimal client (one which does not implement renegotiation): > > sends MCSV on ClientHello, tolerates ServerHellos with extra data > following compression-method, i.e. will complete handshake if that > extra data is 7 octets long and resembles an empty extension RI > > 0x00 0x05 0xFF 0x01 0x00 0x01 0x00 > > and abort the handshake otherwise. OK, but it better do more than tolerate that data, it better require it. By the way, do you of any TLS implementations that do not "implement renegotiation"? I'm sure they exist, but in general renegotiation seems to fall naturally (hmmm, a bit too naturally) out of a straightforward implementation. > RI-minimal server (one which does not implement renegotiation): > > searches MCSV in ClientHello, ignores TLS extensions completely sends > back the above 7 octets extra data after compression_method in > ServerHello when MCSV was found. If you write the spec that way, the world is married to the MCSV forever. And we waste three bytes on every handshake. All for the sake of some unknown-but-small number of servers which fail badly when sent a modern Hello and will probably be put away for their own protection any time now. > RI-only client (one which does not implement TLS extensions in > general but adds secure renegotiation with TLS extension RI): > > minimalistic TLS extensions support, only for TLS extension RI, sends > MCSV in initial ClientHellos, sends TLS extension RI with > Client.Finished.verify_data on renegotiation can parse TLS extension > RI in ServerHello, and in order to reliably recognize updated Servers > on renegotiation, it must be able to find TLS extension RI among > other ServerHello extensions (or abort if there are others) Nothing wrong with that. > RI-only server (one which does not implemet TLS extensions in general > but adds secure renegotiation with TLS extension RI): > > minimalistic TLS extensions support, only for TLS extension RI, can > find and parse TLS extension RI in ClientHello between other > extensions, will send back fixed 7-octet string above on initial > handshakes and TLS extension RI with content on renegotiation > handshakes when the ClientHello contains MCSV or TLS extension RI. Nothing wrong there. Nobody said you had to add general support for extensions. All you have to do is iterate a list of TLVs looking for one type by number. >> Those tiny LoC differences are not significant, especially >> considering the margin of error for those types of things. Usually >> you're lucky to get within a factor of two. > > 20 LoC vs. 80 LoC can be a HUGE difference for old code that one > doesn't know. > > ~20 LoC is 1 day implementing, 1 day testing. ~80 LoC is 3 day > implementing, 5 day testing. I have heard of these teams which produce less than a screenful of code a day. Oh heaven forbid, somebody writes 80 lines of code. Work three days? Do you know how many all-nights and all-weekends I did to get a working test case going for this bug so I could fully characterize it and give the most complete info to people who needed it so they could come up with a workable solution in the shortest period of time to minimize the risk of public disclosure? Every TLS implementation that we could think of and get a non-disclosure agreement with has known about this tentative proposal and the need to implement extensions since the end of September! Most have experimental implementations already. >> They certainly don't give a realistic indication of "level of >> effort". > > I've been doing development, support, maintenance and QA for mission > critical software for the past 14 year, and I can assure you, they do > give a pretty good picture about the effort. > > If you're providing free and open source software, you might not > worry about trial-and-error. > > If you are a software vendor that charges for maintenance, then it is > a completely different issue. You do not change any code that has > been in extended maintenance mode for a few years, and the original > authors of that code are likely not the ones who will have to patch > the code. There are software logistic procedures in place that make > it extremely expensive and extremely unlikely that you make code > changes that break interoperability "unintentionally". > > Have you worked for a software company with 5000+ software developers > during the last three years? No, would you like me to write the 80 LoC for you?. Martin Rex wrote: > Marsh Ray wrote: >> >> In order for this example to be a problem, the legitimate client >> would have to renegotiate specifically for the purpose of dropping >> certain cert credentials. This would seem to imply that the >> application code was expecting cert changes. > > The above code sample provide by Pasi is about client-side code, as > indicated by "openTlsConnection" and the comparison > "conn.getPeerCert().getName() != expected_name" Right. > So this is more about server certificates changing then clients using > different credentials. And it is about apps coding above TLS, and > not about details of TLS implementations. So why would a legitimate server renegotiate a connection and switch certificates in a way that could surprise a client and be manipulated for evil? The renegotiation fix proves it's the same server with no MitM. The last certificate is properly validated and accepted by the client. By extension, this proves the previous connection states were with the trusted server, too, with no interference from a MitM. Whatever such a trusted server wanted to do to the client, he could also do without involving the complexities of a renegotiation. The reverse case applies equally for client certs but seems potentially more plausible because of the way server certs are currently tied to listening IP addresses. > Since a non-negligible amount of clients will need allow old > renegotiation for a little while, one might want to think about > mitigating unexpected changes the server certificate. Again, something bad could possibly happen but nobody's produced an actual scenario. Perhaps something involving multiple sites behind a confused reverse proxy? > There are a lot of applications scenarios where this either doesn't > make any sense or will cause endless problems, support calls and confusion. > Would you want your browser to send *ALL* your WWW-authenticate > credentials to every server and let the server pick (AFAIK the > protocol doesn't even allow that). > In most Audit log facilities, you can only log *ONE* identity for > which an operation was attempted (and failed or succeeded), and not > an arbitrary set of identites. > As soon as you have larger distributed systems, your TLS endpoint > might be a reverse proxy at the perimeter of the backend server farm. > The reverse proxy [...] For HTTPS, a client that shows a different > cert after renegotiation just doesn't make any sense most of the > time. My point wasn't that it was useful most of the time, or even any of the time. My point was that these were the trust relationships implied by the crypto as I understood it. I wouldn't mind being shown to be wrong, but don't really care if you think it's useful or not. > If the client wants to use a different cert, he should open a > new network connection. I do not believe that's not how all https servers work. Usually it's the server asking for a different client cert. For example, Apache will renegotiate for different crypto requirements as the connection traverses different parts of the site. This has been demonstrated with using an .htaccess file to trigger server-initiated renegotiation. > If the reverse proxy or the backend wants to mitigate > session-id-stealing it might employ a memcmp() on the certificates > forwarded by the reverse proxy, and will rightfully abort if that > changes. Sure it might do that. Whether it's rightful or not depends on the application protocol. > A client architecture which allows the use of different client > certificates on different connects and does not reliably distinguish > TLS sessions established with different client properties (anonymous, > client cert A, client cert B, ...) is probably broken. Probably, but only because it seems few were aware of the hidden potential (and pitfalls) provided by TLS renegotiation. >> With renegotiation fixed, credentials supplied on different >> handshakes may legitimately be treated as additive. This is how >> https client certificates often work: an initial anon-client >> connection adds a client cert to the connection by renegotiating. > > Nope, that is not how it works. You'll have to do better than that. > A client that has not been previously > authenticated performs a client cert authentication. That is a > highlander operation. I'm not familiar with that term. Searching for it results in some NSA wiretapping gone wrong. http://www.wired.com/threatlevel/2008/10/kinne/ > Which of the TLS implementation actually keeps > a set of certs/cert-chains for a TLS peer crowd created through > renegotiation and has API calls to iterate through them? The > implementations that I know have only APIs to request "THE" peer > certificate. I believe that list could be maintained by app code using the existing APIs. Better that you don't do it as "getJustTheMostRecentOneRemotePartyCert()" of course. > So if there actually are apps today that can handle a multitude of > client identites on a SSL/SecurityContext handle, they will likely > have to implement that at the app layer, because very few, if any TLS > implementations provide "a set of TLS peers". Well, tell me why it's flawed or I shall have to find an interesting use for it! >> It will never be safe to conduct renegotiation with a remote party >> in the absence of negotiated RI. > > As I wrote a while ago, the name "TLS_RENEGO_PROTECTION_REQUEST" was > chosen _not_ as a requst for secure renegotiation (which it is NOT), > but as a request for _protection_ from the vulnerability through old > TLS renegotiation. Sure. > There are two different issues that the fix needs to provide: > > - secure renegotiation between updated clients and servers directly > talking to each other Yes. > - protection from MitM attacks in all 3 attack scenarios Between which of ((patched|unpatched)x(compatible|strict))**2 x (client-side-renego | server-side-renego | dual-renego) > - protection from MitM attacks for communication between updated > clients and updated servers even when both allow old renegotiation > for backwards interop. Yes > The secure renegotiation is provided by "authenticating" the verify > data from the previous finished messages. I wouldn't describe it that way. It's just checking that two values are in agreement. These values were authenticated by the previous handshake process. Sides have the same, but independent, interests in thwarting MitM. It's natural that they would cooperate to do the checking, but it's not mutual authentication. Each side says "this is who I thought you were, please look after me". Either side could lie when they send the RI data, or fail to check when they receive it, but would gain nothing by doing so. > TLS extension RI performs > the authentication with memcmp() on data exchanged through a TLS > extension in the renegotiation handshake. > > The protection is provided through negotiating/signaling with the > peer that one is updated. The negotiation is only necessary to enable the option of a compatible but insecure mode, it's not part of the security. "Opportunistic security" you might call it, but I hope it is only very temporary. > TLS extension RI does both with the same piece of data in the > handshake message (TLS extension RI), and it seems that some people > fail to understand the difference between the two things. > > Previously, I wrote that draft-mrex-tls-secure-renegotiation-03.txt > is a "nanny spec", because it does _not_only_ describes how to > perform secure renegotiation, but it _also_ describes how to > implement backwards interop securely. This discussion here sugggests > that this difference is unclear to at least some people, and > therefore should be better explained in the > draft-ietf-tls-renegotiation-02 as well! There are definitely some subtle points here. - Marsh From James@Manger.com.au Thu Dec 10 05:00: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 C2DC63A67AB for ; Thu, 10 Dec 2009 05:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gkgalso7o5b for ; Thu, 10 Dec 2009 05:00:00 -0800 (PST) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by core3.amsl.com (Postfix) with ESMTP id 927D43A672F for ; Thu, 10 Dec 2009 04:59:59 -0800 (PST) Received: from nskntotgx01p.mx.bigpond.com ([58.175.155.56]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20091210125946.XUEO21435.nskntmtas04p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com> for ; Thu, 10 Dec 2009 12:59:46 +0000 Received: from [192.168.0.2] (really [58.175.155.56]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20091210125946.QRAX17290.nskntotgx01p.mx.bigpond.com@[192.168.0.2]> for ; Thu, 10 Dec 2009 12:59:46 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: James Manger In-Reply-To: Date: Thu, 10 Dec 2009 23:59:46 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tls@ietf.org X-Mailer: Apple Mail (2.1077) X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4B20F0C2.0085,ss=1,fgs=0 Subject: [TLS] The MCSV hack is a compliment to SSL/TLS designers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 13:00:01 -0000 The Magic Cipher Spec Value (MCSV) is a hack. An empty RI extension is also a hack. The only non-hack solution is a new version number, but that is = impractical. The designers of SSL/TLS should take the fact that a hack is needed to = fix this bug as a compliment. It indicates that SSL/TLS has been so = successful, is used by so many application protocols, on so many = devices, in so many situations that minimising disruption to this = unknowable collection of systems trumps all other criteria for choosing = a fix (other than actually fixing the bug, of course). It trumps = architectural purity; it trumps saving a few bytes; it trumps a few = weeks heads start in developing code. I recommend the approach in draft-mrex-tls-secure-renegotiation-03 (MCSV = in every ClientHello). This approach simply takes out of the equation all the uncertainties = about the prevalence, behaviour, and importance or otherwise of old = versions or limited implementations. --=20 James Manger From Dieter.Bratko@iaik.tugraz.at Thu Dec 10 05: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 484D93A689A for ; Thu, 10 Dec 2009 05:33:57 -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=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=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 rqprIRmjQ1ye for ; Thu, 10 Dec 2009 05:33:55 -0800 (PST) Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by core3.amsl.com (Postfix) with ESMTP id 6EA2E3A67E2 for ; Thu, 10 Dec 2009 05:33:54 -0800 (PST) Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay2.tugraz.at (8.14.3/8.14.3) with ESMTP id nBADXRsp028548; Thu, 10 Dec 2009 14:33:27 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 mailrelay2.tugraz.at nBADXRsp028548 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at; s=mailrelay; t=1260452009; i=@iaik.tugraz.at; bh=vLX2t/3hFpSDh8mXxz41GRkU1MMLZ0+zPhtTFztVrzs=; h=Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; b=TN6CiIgZCzdDo/1lUVcA3p7aBwfUDzeamddu6Ktfw4ybbpAOdiGKCwiZqoHVOHKvn FBQ+eqfimMDGavnWXiw95up/8NF4bdlOZsXIPPRU3HYAOBlnYnCJJtZiyd8t2ea0Vg PbxHICuTa1syex8tb4IubvzZFqPjURv6olHMcizU= Received: from NBDBRATKO (unknown [129.27.152.202]) by thor.iaik.tugraz.at (Postfix) with SMTP id BD6E51067B3B5; Thu, 10 Dec 2009 14:33:27 +0100 (CET) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.2 at thor Message-ID: <666AE669138F434D91E09BED515A4838@iaik.tugraz.at> From: "Dieter Bratko" To: "Michael Gray" , References: Date: Thu, 10 Dec 2009 14:33:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-TUG-Backscatter-control: biYb0C0m31NH2O/F2I9vDw X-Spam-Scanner: SpamAssassin 3.002005 X-Spam-Score-relay: 0.0 X-Scanned-By: MIMEDefang 2.65 on 129.27.10.19 Cc: tls@ietf.org Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 13:33:57 -0000 > Given this large test impact I find the > draft-mrex-tls-secure-renegotiation-03 alternate solution (which does not > require full extension implementation) to be preferable. +1 In environments where you already do a lot of implementation tricks to save code any LoC saving is more than welcome. We have two SSL/TLS libraries, one for J2SE (Java Standard Edition) and one (client-side) for J2ME (Java Micro Edition). Whereas the J2SE version supports TLS extensions, the J2ME version does not (not requested so far). One major goal of our J2ME edition was (and is) to keep its size as small as possible (because this is the main concern of our customers). After implementing and comparing both alternative fixes (for our J2SE library), we would prefer draft-mrex-tls-secure-renegotiation (smaller code size increase, less bandwidth, easier to integrate into SSL and extension-less TLS implementations, therefore less error prone, less test amount and faster deployment). - Dieter ----- Original Message ----- From: "Michael Gray" To: Cc: Sent: Thursday, December 10, 2009 3:16 AM Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV > > mrex@sap.com wrote: > >> Here is my analysis of the requirements and implementation efforts >> for TLS extension RI with magic cipher suites value (MCSV), based on my >> recent experiences from implementing > draft-mrex-tls-secure-renegotiation-03 >> in OpenSSL-0.9.8l and looking at the early implementation of > draft-rescorla >> in the OpenSSL-0.9.8-snapshot. >> >> The purpose of the MCSV is: >> >> - provide interop with installed base of old, extensions-intolerant >> servers (original&correct SSLv3 and "defective" TLSv1.0) >> >> - provide protection from downgrade attacks >> (extension-less ClientHello or SSLv2 ClientHello) >> >> - provide protection in backwards interop scenarios >> (renegotiation requested by old servers). >> >> >> in order to reliably provide this, >> >> - MCSV is defined to represent an empty TLS extension RI >> >> - MSCV MUST be included in *ALL* initial ClientHello handshakes >> messages _plus_ all renegotiation ClientHellos in backwards >> interop scenarios (independent of full handshake or session resume). >> >> - empty TLS extension RI MUST NOT be sent, ever! > > This looks good to me, the only thing I would change is I think MUST NOT > would be better as SHOULD NOT as the later requires that the implementer > examine the conditions and implications etc to make the best decision. We > know that many current browsers always send extensions and for that use > case there is no need to change due to this specification. However we > also > know that there is a large installed base of SSL consuming applications > that are not browser related that have never had any requirement process > extensions and therefore do not support extensions or are extension > intolerant. > > >> - TLS extension RI with Client.Finished.verify_data in ClientHello >> - MUST NOT be sent on renegotiation handshakes in backward >> interop scenarios with old servers which could otherwise break >> - MUST be sent in all other renegotiations >> >> >> If the spec would require that an empty TLS extension RI in a >> ClientHello MUST be completely ignored, then _everyone_ can save 5-10 > LoC. >> >> There is a significant difference between extensions-tolerant and >> extensions-support. Extensions tolerant means, that a server >> will not choke on a ClientHello handshake message, but instead >> simply ignore all data following compression methods compliant >> to the provision in the updated-but-never-published SSLv3, >> TLSv1.0 and TLSv1.1 specs. >> >> In order to implement secure renegotiation with TLS extension RI >> a "generic" TLS extensions parser (~150 LoC) is necessary to >> find the TLS extension RI among other extensions, process it >> and create and process the TLS extension RI reply. > > We used 177 LoC for a generic parser and another 106 LoC for the RI > specific logic. However our experience is that additional effort to back > port into unfamiliar old code is far more costly in time than one would > expect based on LoC count even when considering we have current code that > supports extensions. > > Additionally a large problem is testing this in code bases that do not > support extensions. Manual testing can be done, but that is prone to > error, is costly, and time consuming each time we release code, which > means > we will need to spend a lot more time developing automated testing. > > > >> Support >> for other TLS extensions and API-level access to TLS extensions >> is completely out-of-scope for the following. > > Agree > >> >> >> Adding MCSV to ClientHello on the client and parsing MCSV from >> the ClientHello on the server will typically be <10 LoC each. > > Agree > > >> >> Creating an processing an empty TLS extension RI on the ServerHello >> is also typically <10 LoC each for extension-less implementations. >> >> >> Types of TLS peers in the current installed base: >> >> 1.) old TLS client, no extensions, no renegotiation >> >> 2.) old TLS client, no extensions, renegotiation >> >> 3.) old TLS client, extensions, no renegotiation >> >> 4.) old TLS client, extensions, renegotiation >> >> >> 5.) old TLS server, extensions-intolerant, no renegotiation >> >> 6.) old TLS server, extensions-intolerant, renegotiation >> >> 7.) old TLS server, no extensions, no renegotiation >> >> 8.) old TLS server, no extensions, renegotiation >> >> 9.) old TLS server, extensions, no renegotiation >> >> 10.) old TLS server, extensions, renegotiation >> >> >> The server patches that are currently applied in the field are >> (6) -> (5) >> (8) -> (7) >> (10) -> (9) >> >> >> Additional types of TLS peers when TLS extension RI is implemented: >> >> 11.) updated TLS client, RI-minimal, no renegotiation >> >> 12.) updated TLS client, RI-only, renegotiation >> >> 13.) updated TLS client, extensions, no renegotiation >> >> 14.) updated TLS client, extensions, renegotiation >> >> >> 15.) updated TLS server, RI-minimal, no renegotiation >> >> 16.) updated TLS server, RI-only, renegotiation >> >> 17.) updated TLS server, extensions, no renegotiation >> >> 18.) updated TLS server, extensions, renegotiation >> >> >> >> Effect of requiring MCSV on implementation effort >> -- for non-renegotiating servers: >> >> If we require MSCV on _every_ ClientHello >> then the update (5),(6),(7),(8) -> (15) amounts to ~20 LoC >> the update (9),(10) -> (17) amounts to ~40 LoC >> >> If we do not require MCSV on _every_ ClientHello >> then the update (5),(6),(7),(8) -> (15) amounts to ~80 LoC >> the update (9),(10) -> (17) amounts to ~60 LoC >> >> >> Effect of requiring MCSV on implementation effort >> -- for non-renegotiating clients: >> >> If we require MCSV on _every_ ClientHello, >> then the update (1),(2) -> (11) amounts to ~20 LoC >> (3) -> (13) amounts to ~40 LoC >> >> If we do not require MCSV on _every_ ClientHello, >> then the update (1),(2) -> (11) amounts to ~80 LoC >> (3) -> (13) amounts to ~60 LoC >> > > These are very good numbers and closely match an internal analysis I have > made. > > > It is likely there will be Servers in critical production environments > that > can not be patched (e.g. vendor no longer in business) and they will have > to be fully replaced, as time, planning and evaluation allows (as I noted > here : http://www.imc.org/ietf-tls/mail-archive/msg11082.html) > > > I think the fact that Clients may concurrently interact with Servers of > types 5 to 10, means that the MCSV ONLY proposal is the best solution for > a > low risk deployment. > > >> >> >> guestimates about secure rengotiation efforts: >> >> Servers: these are independent of whether MCSV is required >> (10) -> (18) maybe ~180 LoC >> (6),(8) -> (16) maybe ~200 LoC >> (6),(8) -> (18) maybe ~250 LoC >> >> Clients: these are independend of whether MCSV is required. >> (4) -> (14) maybe ~180 LoC >> (2) -> (12) maybe ~200 LoC >> (2) -> (14) maybe ~250 LoC >> > > > My guess is that at least five times the effort will be required to add > testing of this into existing auto test harnesses for code levels that do > not support extensions. Interestingly this vulnerability fix is the only > reason these old code levels now need to support extensions. > > Given this large test impact I find the > draft-mrex-tls-secure-renegotiation-03 alternate solution (which does not > require full extension implementation) to be preferable. > > - Mick > >> _______________________________________________ >> 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 ynir@checkpoint.com Thu Dec 10 05:39: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 053DA3A692D for ; Thu, 10 Dec 2009 05:39:02 -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 6+lwAC+atp5Q for ; Thu, 10 Dec 2009 05:39:01 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F2ED53A689A for ; Thu, 10 Dec 2009 05:39:00 -0800 (PST) X-CheckPoint: {4B20F955-10001-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9674029C004; Thu, 10 Dec 2009 15:38:45 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7D6C929C002; Thu, 10 Dec 2009 15:38:45 +0200 (IST) X-CheckPoint: {4B20F952-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBADcjT7024442; Thu, 10 Dec 2009 15:38:45 +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, 10 Dec 2009 15:38:56 +0200 From: Yoav Nir To: James Manger Date: Thu, 10 Dec 2009 15:38:41 +0200 Thread-Topic: [TLS] The MCSV hack is a compliment to SSL/TLS designers Thread-Index: Acp5nh5uWKPsdQgYT3m09ejHsxwezA== Message-ID: <632A26DD-AA1C-48DF-9CEB-D797B80A9077@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] The MCSV hack is a compliment to SSL/TLS designers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 13:39:02 -0000 +! On Dec 10, 2009, at 2:59 PM, James Manger wrote: > The Magic Cipher Spec Value (MCSV) is a hack. > An empty RI extension is also a hack. > The only non-hack solution is a new version number, but that is impractic= al. >=20 > The designers of SSL/TLS should take the fact that a hack is needed to fi= x this bug as a compliment. It indicates that SSL/TLS has been so successfu= l, is used by so many application protocols, on so many devices, in so many= situations that minimising disruption to this unknowable collection of sys= tems trumps all other criteria for choosing a fix (other than actually fixi= ng the bug, of course). It trumps architectural purity; it trumps saving a = few bytes; it trumps a few weeks heads start in developing code. >=20 > I recommend the approach in draft-mrex-tls-secure-renegotiation-03 (MCSV = in every ClientHello). >=20 > This approach simply takes out of the equation all the uncertainties abou= t the prevalence, behaviour, and importance or otherwise of old versions or= limited implementations. >=20 > --=20 > James Manger From mrex@sap.com Thu Dec 10 08:13: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 970F53A69E4 for ; Thu, 10 Dec 2009 08:13:25 -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 PmdB7uXcQ8DR for ; Thu, 10 Dec 2009 08:13:20 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 15BBC3A6A9E for ; Thu, 10 Dec 2009 08:13:18 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBAGD4JO001667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 17:13:04 +0100 (MET) From: Martin Rex Message-Id: <200912101613.nBAGD3X2016314@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 10 Dec 2009 17:13:03 +0100 (MET) In-Reply-To: <4B20ABA4.3050805@extendedsubset.com> from "Marsh Ray" at Dec 10, 9 02:04: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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 10 Dec 2009 16:13:26 -0000 Marsh Ray wrote: > > Apologies in advance if this doesn't all get quoted perfectly. > > Martin Rex wrote: > > Marsh Ray wrote: > >> The draft-freier-ssl-version3-02.txt says to ignore data after the > >> Client Hello, which implies extension-intolerant SSLv3 servers are > >> defective, too. Not that it really matters at this point. Had you > >> mentioned something about an earlier version not saying that? > > > > The official SSLv3 spec doesn't say that! > > > > The IETF archives do not know freier-ssl-version3-02 (only -00 and > > -01) freier-ssl-version3-02 is probably what is known as > > draft-ietf-tls-ssl-version3-00.txt -- a document which the TLS WG > > chose _NOT_ to publish as informational, and which Netscape did _NOT_ > > see as an official spec, otherwise they would have updated their much > > more prominently offered versions of the SSLv3 spec based on the > > freier -01 draft _without_ the extensibility option. > > That is interesting information. Would you happen to have a copy of the > last "official" spec you can send me? Netscape's official SSLv3 spec as of 2005: http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM > > The IETF's DNS seems to be inoperative, but Google has a cached version of: > http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 > > It has the same "it is permitted for a client hello message to include > extra data after the compression methods" language. As obvious from it's name that spec is a product of the TLS WG and the TLS WG decided to completely abandon (instead of publishing as informational RFC) that document so that it expired and vanished from the I-D repository 6 month later. > > Servers receiving an initial connection request without a request for RI > will soon know some things: > > 1. The client software is not patched for security. > > 2. There's a good chance the client is vulnerable to one or more > variants of this basic attack. If that is the impression that the current draft-ietf-tls-renegotiation-01 leaves with you, then this draft needs MAJOR updates of the description, because it is not correct. One obvious problem with draft-ietf-tls-renegotiation-01.txt is that is extremely underspecified. The TLS extension RI is overloaded in semantics, and the spec doesn't spell it out. In the original definition (without MCSV) TLS extension RI conveys three distinct pieces of information: 1.) indication that the TLS peer is updated for secure renegotiation (1 bit of information) 2.) indication of whether the TLS peer is performing an initial or a renegotiation handshake (1 bit of information) 3.) identification of the previous TLS session the TLS peer assumes to be renegotiating Since all of this information is carried in the same TLS extension, a correct spec and a correct implementation is a little complex. Since the current document does not make this clear, the decision what to send, in particular for backwards interop scenarios, is non-obvious -- and obviously some people on this list, which I believe to be experienced engineers, seem to have gotten this wrong. The reason why my proposal is actually much simpler to explain in full detail and simpler to implement, is that it uses two completely seperate mechanisms to convey (1) and to achieve (3) and it doesn't do (2) at all. (Not doing 2 means that MitM attacks can not be distinguished from other finished MAC errors im my I-D). For interop scenarios with old servers, and as currently used by conservative clients and reconnect fallbacks (extension-less ClientHellos, SSLv3 ClientHellos and SSLv2 ClientHellos), sending a TLS extension in the initial ClientHello would be a change with a significant disruptive potential. Not sending any indiciation of the update for TLS renego protection leaves vulnerabilities, therefore MCSV is used. >From the server reply (ServerHello), the client can determine whether it is talking to an old or an updated server--the updated Server will return a TLS extension RI in ServerHello. When the client has established a TLS session with a presumably old server, and that server asks for renegotiation for whatever reason (or maybe the client wants renegotiation for client identity protection), then TLS extension RI is of *NO* use at all. The only thing that TLS extension RI on the renegotiation ClientHello with an old server is interop problems. But not sending anything would make the renegotiation vulnerable to a "downgrade attack" with an updated server. Therefore we need to use MCSV for the renegotiation with an old server. MCSV will allow an updated server in an MitM scenario to prevent a renegotiation handshake from succeeding. If the updated server receives the MCSV on an initial handshake, it will reply with an empty TLS extension RI, which will allow the client to determine whether his renegotiation with an presumably old server is proxied into the initial handshake of an updated server, so the client MUST abort. If the updated server receives the MCSV in a renegotiation handshake, but no accompanying TLS extension RI with the client_verify data, then the server MUST abort the renegotiation handshake because this is likely an updated's clients initial handshake that is proxied into the renegotiation handshake of an updated server. > > Clients receiving a request for renegotiation without having previously > negotiated RI can expect that the server is vulnerable to MitM and they > may have already been pwned on this connection state. The client should not try to rationalize what and what not a server might be doing. The client should look at the handshake reply, look at its policy/configuration and either abort the handshake or continue. > > Servers receiving a client-initiated renegotiation without having > previously negotiated RI can not know that it is the same party they > have on the current connection state. Similarly, servers should not try to rationalize about clients, but instead rely on policy/configuration and implement behaviour that is mostly failsafe. If an updated server receives a ClientHello on a renegotiation handshake that carries an MCSV, but lacks the TLS extension RI containing the Client.Finished.verify_data, then that server MUST abort the handshake. > > Starting soon, the absence of RI on a hello is going to be an > increasingly strong indicator of "broken and insecure". Eventually, it > will just be discarded along with SSLv1 and v2. Nope, it will be an MitM on backwards interopble clients, and many of those clients will be updated and capable to send MCSV. > > > If we do not provide provisions for smooth interop for at least the > > transition period, it will hurt _everyone_! > > If you really want to renegotiate with old, broken, unpatched, and > extension-intolerant servers so badly that you're willing to do it > insecurely then don't send them the freaking extension! > > Sending them an MCSV is at best going to be ignored by such a server, no > matter what semantics some document attaches to it. You're _not_ sending the MCSV for use by that old server, you're including it so that this ClientHello can not be diverted/proxied into the handshake of an updated server and result in a successful handshake if that server is backwards interoperable. > > >> Lots of clients (browsers, etc) currently do send extensions on > >> Client Hello, so they may never choose to send MCSV on those > >> connections. > > > > Several hundred millions clients do _not_ send extensions on > > ClientHello. > > Not relevant. What matters is the number of servers that hang in a slow > fail condition when sent an extension. During my tests with openssl-0.9.8l I noticed that a client sending a renegotiation ClientHello to openssl-0.9.8l will hang. An openssl-0.9.8l server seems to _not_ reply to this ClientHello (with a no_renegotiation alert), but instead completely ignore the handshake message. Not good. > > Look, SSLv3 is broken. SSLv3 isn't broken. It was just _not_ designed to be extensible. If you look at TLS, it is not that much better. It took them 7 years to define extensibility. They could have simply added a 4-octet bitfield for future assignment as the first piece of TLS extensions right into the TLSv1.0 spec. If all you need to convey is a single bit of information, then a single bit in a relatively fixed location of a handshake message is _so_ much easier to use than the generic TLS extensions carriage. > > Sure there is: some clients get a positive benefit from the use of > extensions. How to manage the tradeoff between that benefit vs. > potential interactions with intolerant servers is something app > developers and admins/users currently manage. As long as there are extensions-intolerant servers still in use, only clients that have a re-connect fallback mechanism can benefit. You may ship completely new products without fallbacks, but if you are a software vendor, you definitely can not hotfix disruptive changes into the installed base unless it is absolutely unavoidable and your customers are willing to accept this. For secure TLS renegotiation, the use of TLS extensions in a disruptive fashion is easily and clearly avoidable. > > > For an updated server in an MitM attack scenario, the presence of the > > MCSV is sufficient to realize that it is talking to an updated client > > that is probing. > > Right. After that initial Client Hello with the MCSV, the server knows > that the client is patched and responds with an extension. From that > point on, the client knows he can send extensions. And both endpoints > now must send the extension on every single hello on that connection, > because they will have nonempty verify_data. ... I actually wrote about an MitM attack scenario here, where the description of the further communication should describe which of the peers should at which point realize that it is an attack and abort -- and not how they would securely renegotiate. ;-) > > > You're confused. > > Wouldn't be the first time. I assume I am simply writing too much and make it difficult for others to follow my line of thought that way. I'm sorry for that. It is not my intention to confuse. > > > This requirement is about protection from MitM-attacks, it is _NOT_ > > about successful secure renegotiations (which are not possible when > > talking to an old server in backwards interop mode). > > Sorry, which requirement was that? Sending the MCSV on _every_ ClientHello (initial *AND* renegotiations). > > > We do not need two signaling mechanisms where one is perfectly > > sufficient. > > I don't think one is perfectly sufficient. Keep in mind the attacker > generally gets to choose which handshake is presented where. One signaling mechanism (MCSV) to for conveying Client->Server that the client is updated is perfectly sufficient. For signaling that a client is performing a secure renegotiation with an updated server and for identifying the previous TLS session that the client presumes to be renegotiating, that is what TLS extension RI containing Client.Finished.verify_data is about. > > Patched clients and servers must validate the content of the (now > required to be present and nonempty) RI extension received on subsequent > Hellos. The MCSV field on subsequent Client Hellos is now redundant in > all cases (both valid and attack). No, it isn't. It enables RI-minimal implemementations of old TLS servers to detect proxied handshakes with updated MitMs. You might want to take the position, that it is the client who is being fooled, so only the client needs to be aware of the attack, but *I* think that would be an incomplete fix. > > >> So you're saying that an implementor who has let their code rot for > >> the last 6.5 years could save 140 LoC? > >> > >> Personally, I don't find that to be a primary consideration. > > > > Rot for 6.5 years? What are you talking about? > > RFC 3546 TLS Extensions June 2003 > > > There is even brand new code under active maintenance without support > > for TLS extensions. > > Well, guess what! The protocol now needs to be extended. No, it doesn't. It needs to be fixed! > > TLS extensions is purely optional, not part of the vulnerability > > and does not need to be part of the solution. > > No one came up with any other less-impactful way to do the required S->C > signaling, and not for lack of trying. Plain Wrong. My proposal works without TLS extensions, that is clearly explained. It just happens to use a S->C signaling scheme that looks like TLS extensions to TLS-extensions aware implementations and can be parsed with TLS extensions parsers, for those who prefer to do it that way. But my draft explains clearly how to do it without TLS extensions, and the OpenSSL patch I posted contains an extension-less implementation of the signaling -- and the Client side of the extension-less code is actually used for server_version==SSL3_VERSION. > > > Besides, in those cases where it is about code that has been mostly > > unchanged for 6+ years, it is not "implementers" who will have to add > > the secure renegotiation patch, it will often be "maintainers" with > > little knowledge about the code -- and then, it makes perfect sense > > to ask them for only 20 lines of code instead of 150+ > > There's no 20 line fix for this. Neither is there a (palatable) solution > which does not use extensions. Last I checked, > draft-mrex-tls-secure-renegotiation used an extension. Oh yes, there is. Look at the last two paragraphs of Section 4.4 which describe how extension-less clients and extension-less servers can implement this with <10 LoC each. And my openssl-patch contains exactly that code. > > >> Could you explain what you mean by RI-minimal, RI-only, and > >> "extensions". > > > > RI-minimal client (one which does not implement renegotiation): > > > > sends MCSV on ClientHello, tolerates ServerHellos with extra data > > following compression-method, i.e. will complete handshake if that > > extra data is 7 octets long and resembles an empty extension RI > > > > 0x00 0x05 0xFF 0x01 0x00 0x01 0x00 > > > > and abort the handshake otherwise. > > OK, but it better do more than tolerate that data, it better require it. > > By the way, do you of any TLS implementations that do not "implement > renegotiation"? There are two possibilities with the same effect: Do not implement it in the fashion of "have never contained it" and do not implement it in the fashion that it is hardwired to disabled. openssl-0.9.8l is one of the latter. What you currently see is a lot of customers asking for patches that reliably disable renegotiation for the servers, because most servers do _not_ need it. And once you've come to the conclusion that you don't really need it, there is no use to implement full secure TLS renegitiation. RI-minimal would be just fine, and much easier to test and ship as a hotfix for an old installed base. > > I'm sure they exist, but in general renegotiation seems to fall > naturally (hmmm, a bit too naturally) out of a straightforward > implementation. > > > RI-minimal server (one which does not implement renegotiation): > > > > searches MCSV in ClientHello, ignores TLS extensions completely sends > > back the above 7 octets extra data after compression_method in > > ServerHello when MCSV was found. > > If you write the spec that way, the world is married to the MCSV > forever. And we waste three bytes on every handshake. Cipher suite values in SSLv3/TLS are two bytes, and if you're really concerned about that, you should go for draft-mrex-tls-secure-renegotiation, because it will need even less bytes on every handshake, in particular on the renegotiation handshakes. If TLS extension RI specifies to NOT send an empty TLS extension RI on the initial handshake EVER, only MCSV, and additionally include MCSV on every renegotiation handshake, then you save 3-5 bytes on every initial handshake and pay 2 bytes extra on every renegotiation. That means for >95% of the usage scenarios you will save. > > > 20 LoC vs. 80 LoC can be a HUGE difference for old code that one > > doesn't know. > > > > ~20 LoC is 1 day implementing, 1 day testing. ~80 LoC is 3 day > > implementing, 5 day testing. > > I have heard of these teams which produce less than a screenful of code > a day. > > Oh heaven forbid, somebody writes 80 lines of code. > > Work three days? Do you know how many all-nights and all-weekends I did > to get a working test case going for this bug so I could fully > characterize it and give the most complete info to people who needed it > so they could come up with a workable solution in the shortest period of > time to minimize the risk of public disclosure? Every TLS implementation > that we could think of and get a non-disclosure agreement with has known > about this tentative proposal and the need to implement extensions since > the end of September! Most have experimental implementations already. I can imagine that it takes quite some time to implement an MitM attack on TLS renegotiation. I'm sorry for just thinking about it for an hour, checking the TLS spec for flaws in my line of thought for 20 minutes and then posting it publicly to tls@ietf.org that TLS renegotiation is susceptible to MitM attacks. > > > > > Have you worked for a software company with 5000+ software developers > > during the last three years? > > No, would you like me to write the 80 LoC for you?. I don't have problems with writing that code. But you certainly could help me with the weeks of paperwork and automated test-cases necessary to get official permission to ship that change into an installed base in maintenance mode. Some 10 LoC changes require 300+ LoC test tools. If you look at my openssl patch, it does not create a lot of new code pathes that can only be reached with test tools. 98% of that new code is fully covered during regular use/interop, and works in a failsafe fashion -- i.e. if it didn't work as designed, it would result in interop problems. > > So why would a legitimate server renegotiate a connection and switch > certificates in a way that could surprise a client and be manipulated > for evil? The renegotiation fix proves it's the same server with no > MitM. It _only_ proves there is no MitM acting without consent of that server. If that server changes his certificate during renegotiation, it is DEFINITELY not the same server as before. Depending on what the new cert looks like, the client may accept this change, but the assumption that a client must not care is flawed, and can by itself become a security problem for some situations. If you're doing security-related stuff, it is extremely important that you are staying clean at the abstract level. Some of the risks that one creates by sloppiness at the abstract level may lead to mostly theoretical vulnerabilities (like adding arbitrary data to the handshake message hash instead of handshake messages), and sometimes it can create very practical risks (like ignoring identity changes). > > The reverse case applies equally for client certs but seems potentially > more plausible because of the way server certs are currently tied to > listening IP addresses. There are some apps on top of TLS that "tie" certs to hostnames, but as previously discussed, that is entirely an apps issue, and the TLS implementation can _NOT_ force re-authentication on the application caller! > > > Since a non-negligible amount of clients will need allow old > > renegotiation for a little while, one might want to think about > > mitigating unexpected changes the server certificate. > > Again, something bad could possibly happen but nobody's produced an > actual scenario. Perhaps something involving multiple sites behind a > confused reverse proxy? In the IETF security area we try to avoid this kind of approach: worrying about vulnerabilities only when exploits have been published. We want to move away from MD5 in online authentication even though nobody has demonstrated real-time second preimage attacks against MD5 yet. > > > A client that has not been previously > > authenticated performs a client cert authentication. That is a > > highlander operation. > > I'm not familiar with that term. Searching for it results in some NSA > wiretapping gone wrong. > http://www.wired.com/threatlevel/2008/10/kinne/ You mean the term "highlander"? Look here: http://en.wikipedia.org/wiki/Highlander_%28film%29 "in the end, there can be only one." > > > Which of the TLS implementation actually keeps > > a set of certs/cert-chains for a TLS peer crowd created through > > renegotiation and has API calls to iterate through them? The > > implementations that I know have only APIs to request "THE" peer > > certificate. > > I believe that list could be maintained by app code using the existing > APIs. Better that you don't do it as > "getJustTheMostRecentOneRemotePartyCert()" of course. > > > So if there actually are apps today that can handle a multitude of > > client identites on a SSL/SecurityContext handle, they will likely > > have to implement that at the app layer, because very few, if any TLS > > implementations provide "a set of TLS peers". > > Well, tell me why it's flawed or I shall have to find an interesting use > for it! To have more than one client cert listed for an authenticated TLS session would be a pretty dumb idea. There are platforms that offer such mechanisms more like a feature of the "Trusted Computing Base", which allows to pass of ACL checks in a Posix-ACL style to the underlying OS (ImpersonateSecurityContext()). These functions would likely have difficulties dealing with a set-of instead of a single client identity, and they would be faced with the problem that Access Control and auditing/audit logs can deal only with a single Access Token (identity). > > > The secure renegotiation is provided by "authenticating" the verify > > data from the previous finished messages. > > I wouldn't describe it that way. It's just checking that two values are > in agreement. These values were authenticated by the previous handshake > process. That is what is supposed to happen. I know that TLS extension RI uses an unconventional way to perform this authentication -- it exchanges the data in an integrity-protected fashion and needs to memcmp() the contents. Which is why TLS extension RI is not failSAFE. -Martin From marsh@extendedsubset.com Thu Dec 10 08:54: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 A9C033A6832 for ; Thu, 10 Dec 2009 08:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3892zwjd1KA for ; Thu, 10 Dec 2009 08:54:44 -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 D55F03A67F5 for ; Thu, 10 Dec 2009 08:54: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 1NImHe-000Fp1-RG; Thu, 10 Dec 2009 16:54:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7A5B6603A; Thu, 10 Dec 2009 16:54: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+4Z6iRuc2SAN7Rr4wo+WDyrnIOT1jRW8M= Message-ID: <4B2127C2.5060307@extendedsubset.com> Date: Thu, 10 Dec 2009 10:54:26 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: James Manger References: In-Reply-To: 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] The MCSV hack is a compliment to SSL/TLS designers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 16:54:44 -0000 James Manger wrote: > The Magic Cipher Spec Value (MCSV) is a hack. Yes. > An empty RI extension is also a hack. No, it's a well-defined and appropriate way of communicating an important bit of information over the protocol, namely: "I support the renegotiation fix and my belief is that we have had no previous connection state on this connection". > The only non-hack solution is a new version number, but that is > impractical. Which is why most well-designed nontrivial protocols have an extension mechanism. > The designers of SSL/TLS should take the fact that a hack is needed > to fix this bug as a compliment. I wouldn't. > It indicates that SSL/TLS has been so successful, is used by so many > application protocols, on so many devices, in so many situations that > minimising disruption to this unknowable collection of systems trumps > all other criteria for choosing a fix (other than actually fixing the > bug, of course). It has been very successful yes, and that is at least in part because the designers did many things right. > It trumps architectural purity; it trumps saving a few bytes; it > trumps a few weeks heads start in developing code. That's not a good thing. > I recommend the approach in draft-mrex-tls-secure-renegotiation-03 > (MCSV in every ClientHello). It also requires the use of an extension. > This approach simply takes out of the equation all the uncertainties > about the prevalence, behaviour, and importance or otherwise of old > versions or limited implementations. No it doesn't. - Marsh From cfinss@dial.pipex.com Thu Dec 10 09:08: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 C93903A6AF5 for ; Thu, 10 Dec 2009 09:08: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 R3x5Z+dItJX6 for ; Thu, 10 Dec 2009 09:08:52 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 7BC023A6ACF for ; Thu, 10 Dec 2009 09:08:52 -0800 (PST) X-Trace: 165873801/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.202/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.202 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8GADe6IEs+vGTK/2dsb2JhbACCfIV0iF3GEAqEIQQ X-IronPort-AV: E=Sophos;i="4.47,375,1257120000"; d="scan'208";a="165873801" X-IP-Direction: IN Received: from 1cust202.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.202]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Dec 2009 17:08:39 +0000 Message-ID: <010901ca79b3$29d65660$0601a8c0@allison> From: "tom.petch" To: "Eric Rescorla" , References: <20091207220427.E36B16C5243@kilo.networkresonance.com> Date: Thu, 10 Dec 2009 17:08:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [TLS] What is spliced X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:08:53 -0000 ----- Original Message ----- From: "Eric Rescorla" Sent: Monday, December 07, 2009 11:04 PM Subject: [TLS] What is spliced > There has been a bunch of discussion about what the introduction should > say about what is spliced together in this attack. Here's my proposed > new text, based on trying to integrate various comments from Nelson, > Marsh, etc. > > This attack can be prevented by cryptographically binding > renegotiation handshakes to the enclosing TLS channel, or more > properly, to the TLS handshake which established the security > parameters over which the new handshake is being performed. This > prevents the attacker from splicing a negotiation occuring over one > set of security parameters (including the initial pre-handshake > set of TLS_NULL_WITH_NULL_NULL) into > another set of security parameters. An attempt by an attacker to > inject himself as described above will result in a mismatch of the > extension and can thus be detected. The data used in the extension is > similar to, but not the same as, the channel binding data used in > [I-D.altman-tls-channel-bindings], however this extension is not a > generic-purpose RFC 5056 channel binding facility. > > Comments? Eric - What is spliced:-) As Martin says in another response, I would prefer a single term, and spliced is not one I see anywhere else. Would injected, which is the verb used in the next sentence, not be adequate? (I rewrote 1.Introduction using 'Injected Data' and found it easier to follow) - Why is the injection/splice into a set of security parameters? Isn't the injection into a TLS session with a different set of security parameters? - In the absence of Nico, I suggest that 'channel binding data' should be 'channel bindings data' - as RFC5056 says, channel binding is the process, channel bindings is the data. - One point I have got confused on in the discussions is which set of data is used; this text implies that it will be from the most recent re-negotiation as opposed to that from the negotiation which established the session in the first place. If so, the text could be more explicit eg 'most recent TLS handshake/(re-)negotiation'. Nico's use of channel, with which I concur, is the channel stays the same no matter how many renegotiations occur, which. for me, makes this proposed text less clear. Tom Petch > > -Ekr From mrex@sap.com Thu Dec 10 09:22: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 6E8EB3A6897 for ; Thu, 10 Dec 2009 09:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 vGe4clvv8bi5 for ; Thu, 10 Dec 2009 09:22: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 3EBFC3A6801 for ; Thu, 10 Dec 2009 09:22:25 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBAHMAFF015413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 18:22:10 +0100 (MET) From: Martin Rex Message-Id: <200912101722.nBAHM9iR022569@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 10 Dec 2009 18:22:09 +0100 (MET) In-Reply-To: <4B2127C2.5060307@extendedsubset.com> from "Marsh Ray" at Dec 10, 9 10:54:26 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, James@Manger.com.au Subject: Re: [TLS] The MCSV hack is a compliment to SSL/TLS designers 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, 10 Dec 2009 17:22:26 -0000 Marsh Ray wrote: > > > I recommend the approach in draft-mrex-tls-secure-renegotiation-03 > > (MCSV in every ClientHello). > > It also requires the use of an extension. No, it does NOT. draft-mrex-tls-secure-renegotiation-03 uses additional data following the compression_method in ServerHello for Server->Client signaling. See Section 4.4 last two paragraphs of that draft. That extra data is designed to be compatible with TLS extensions, but it can be processed like a static 6-octet string by extensions-free implementations. Clients that _send_ TLS extensions in ClientHello will have to search the S->C signal among the TLS extensions in ServerHello -- but that is an obvious side-effect of asking for TLS extension in ClientHello. -Martin From mrex@sap.com Thu Dec 10 09:55: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 D2F9E3A6B41 for ; Thu, 10 Dec 2009 09:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 5mTLTqaPATLJ for ; Thu, 10 Dec 2009 09:55:21 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id C27393A6AEF for ; Thu, 10 Dec 2009 09:55:20 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBAHrvFG018828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 18:53:57 +0100 (MET) From: Martin Rex Message-Id: <200912101753.nBAHruDG024522@fs4113.wdf.sap.corp> To: cfinss@dial.pipex.com Date: Thu, 10 Dec 2009 18:53:56 +0100 (MET) In-Reply-To: <010901ca79b3$29d65660$0601a8c0@allison> from "tom.petch" at Dec 10, 9 05:08: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] What is spliced 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, 10 Dec 2009 17:55:21 -0000 tom.petch wrote: > > - What is spliced:-) As Martin says in another response, I would prefer > a single term, and spliced is not one I see anywhere else. Would injected, > which is the verb used in the next sentence, not be adequate? (I rewrote > 1.Introduction using 'Injected Data' and found it easier to follow) IMHO the splicing fully applies only to attack scenario (3), where both TLS peers see a renegotiation, but for different enclosing TLS sessions. > > - Why is the injection/splice into a set of security parameters? Isn't the > injection into a TLS session with a different set of security parameters? I think it would be better do define the terminology "TLS session" "TLS connection" rather than trying to avoid the word "session" and refer to the connection state instead (that is terminology carried over from the SSLv3 spec into TLSv1.2/RFC-5246). On quick glance, the removal of terminology session/connection from draft-ietf-tls-ssl-version3.txt 5.1 Session and connection states to rfc-5246 6.1 Connection States appear to _me_ more confusing than helpful. > > - One point I have got confused on in the discussions is which set of data > is used; this text implies that it will be from the most recent re-negotiation > as opposed to that from the negotiation which established the session in > the first place. If so, the text could be more explicit eg 'most recent TLS > handshake/(re-)negotiation'. Nico's use of channel, with which I concur, > is the channel stays the same no matter how many renegotiations occur, > which, for me, makes this proposed text less clear. I fully agree. After having read draft-altman-tls-channel-bindings-07.txt Sections 3. and 3.1 I think that referencing that draft will do more harm than good, because it is obviously _NOT_ the same -- during the processing of the finished messages of the renegotiation, the previous Finished.verify_data will be overwritten and gone. Implementations of draft-altman-tls-channel-bindings-07.txt will require additional session state for TLS implementations to be added (if the TLS implementation supports renegotiation). >From a conceptual standpoint, secure TLS renegotiation should better bind to the previous handshake, not to the initial one on a communication channel. The concept of retroactively considering all data authenticated that came through previous TLS sessions is an application concept, _not_ one of TLS. It might be OK for some applications to make such assumptions, provided they get their part of the identity change during renegotiation properly managed, but it is definitely something that TLS should buy into _in_general_. IMHO. -Martin From mrex@sap.com Thu Dec 10 10:12: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 C43683A6894 for ; Thu, 10 Dec 2009 10:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=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 bs8qdPDQrFgY for ; Thu, 10 Dec 2009 10:12: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 22D413A6826 for ; Thu, 10 Dec 2009 10:12:05 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBAIBotC008969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 19:11:50 +0100 (MET) From: Martin Rex Message-Id: <200912101811.nBAIBnNR025986@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 10 Dec 2009 19:11:49 +0100 (MET) In-Reply-To: <200912101753.nBAHruDG024522@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 10, 9 06:53:56 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] What is spliced 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, 10 Dec 2009 18:12:09 -0000 (partially obvious) typo in last line of my previous posting. Martin Rex wrote: > > tom.petch wrote: > > > > - What is spliced:-) As Martin says in another response, I would prefer > > a single term, and spliced is not one I see anywhere else. Would injected, > > which is the verb used in the next sentence, not be adequate? (I rewrote > > 1.Introduction using 'Injected Data' and found it easier to follow) > > IMHO the splicing fully applies only to attack scenario (3), where both > TLS peers see a renegotiation, but for different enclosing TLS sessions. > > > > > > - Why is the injection/splice into a set of security parameters? Isn't the > > injection into a TLS session with a different set of security parameters? > > I think it would be better do define the terminology "TLS session" > "TLS connection" rather than trying to avoid the word "session" and > refer to the connection state instead (that is terminology carried > over from the SSLv3 spec into TLSv1.2/RFC-5246). > > On quick glance, the removal of terminology session/connection > from draft-ietf-tls-ssl-version3.txt 5.1 Session and connection states > to rfc-5246 6.1 Connection States appear to _me_ more confusing > than helpful. > > > > > > - One point I have got confused on in the discussions is which set of data > > is used; this text implies that it will be from the most recent re-negotiation > > as opposed to that from the negotiation which established the session in > > the first place. If so, the text could be more explicit eg 'most recent TLS > > handshake/(re-)negotiation'. Nico's use of channel, with which I concur, > > is the channel stays the same no matter how many renegotiations occur, > > which, for me, makes this proposed text less clear. > > > I fully agree. After having read draft-altman-tls-channel-bindings-07.txt > Sections 3. and 3.1 I think that referencing that draft will do more > harm than good, because it is obviously _NOT_ the same -- during > the processing of the finished messages of the renegotiation, the > previous Finished.verify_data will be overwritten and gone. > > Implementations of draft-altman-tls-channel-bindings-07.txt will > require additional session state for TLS implementations to be added > (if the TLS implementation supports renegotiation). > > From a conceptual standpoint, secure TLS renegotiation should > better bind to the previous handshake, not to the initial one on > a communication channel. > > The concept of retroactively considering all data authenticated > that came through previous TLS sessions is an application concept, > _not_ one of TLS. It might be OK for some applications to make > such assumptions, provided they get their part of the identity > change during renegotiation properly managed, but it is definitely - something that TLS should buy into _in_general_. IMHO. + something that TLS should _not_ buy into _in_general_. IMHO. -Martin From paul.hoffman@vpnc.org Thu Dec 10 10:24: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 598883A6A2D for ; Thu, 10 Dec 2009 10:24:04 -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 HaYVou5XUpe5 for ; Thu, 10 Dec 2009 10:24:03 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 9A4C73A68B7 for ; Thu, 10 Dec 2009 10:24:03 -0800 (PST) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBAINoUL044971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Dec 2009 11:23:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 10 Dec 2009 10:23:50 -0800 To: tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [TLS] Please be specific: RI alone, RI with MCSV, or MCSV alone X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 18:24:04 -0000 While following the numerous threads, it seems that some people are advocating adding MCSV to RI, while others are advocating RI by itself (no MCSV), while others are advocating MCSV by itself (instead of RI). Can people please be more specific which proposal they are advocating? It greatly affects the conversation. Thanks! --Paul Hoffman, Director --VPN Consortium From marsh@extendedsubset.com Thu Dec 10 10:46: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 549723A68A6 for ; Thu, 10 Dec 2009 10:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_43=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 EvfN0WgAI1xF for ; Thu, 10 Dec 2009 10:46: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 3FF403A67E6 for ; Thu, 10 Dec 2009 10:46: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 1NIo2B-0005zH-Ec; Thu, 10 Dec 2009 18:46:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A1354603A; Thu, 10 Dec 2009 18:46: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/0Ae807Uc8hgGwxbL1INs2vYD0bIp3s3c= Message-ID: <4B214209.6020304@extendedsubset.com> Date: Thu, 10 Dec 2009 12:46:33 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912101722.nBAHM9iR022569@fs4113.wdf.sap.corp> In-Reply-To: <200912101722.nBAHM9iR022569@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: multipart/mixed; boundary="------------060905010508040002010208" Cc: tls@ietf.org, James@Manger.com.au Subject: [TLS] How to wade through Hello extensions was: The MCSV hack is a compliment to SSL/TLS designers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 18:46:52 -0000 This is a multi-part message in MIME format. --------------060905010508040002010208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > Marsh Ray wrote: >>> I recommend the approach in draft-mrex-tls-secure-renegotiation-03 >>> (MCSV in every ClientHello). >> It also requires the use of an extension. > > No, it does NOT. > > draft-mrex-tls-secure-renegotiation-03 uses additional data following > the compression_method in ServerHello for Server->Client signaling. > See Section 4.4 last two paragraphs of that draft. > > That extra data is designed to be compatible with TLS extensions, > but it can be processed like a static 6-octet string by extensions-free > implementations. Hmmm, an additional six bytes after a hello: 0x00 0x04 0xFF 0x01 0x00 0x00 I'd call that an extension. The only difference is that in draft-ietf-tls-renegotiation it contains useful payload data on renegotiation handshakes. > Clients that _send_ TLS extensions in ClientHello will have to search > the S->C signal among the TLS extensions in ServerHello -- but that > is an obvious side-effect of asking for TLS extension in ClientHello. Right. And in draft-ietf-tls-renegotiation you have to be able to iterate extensions on any hello message. Not a big deal. In any case, you've had six and a half years to prepare yourself for it. Hmm, let's see how long it takes me to write this in C++. Starting typing code at 11:41 AM Finished primary functiat at 11:59. So the basic "wade through the list of extensions" function came out to 51 LoC (including comments and gratuitous whitespace) and 18 minutes. Wonder if it compiles? Fixed typo assert(extId); should be assert(extType); Fixed type error *rv.assign(p, p + statedExtDataLen); should be rv->assign(p, p + statedExtDataLen); (I updated the version pasted above) Compiles cleanly at 12:04, time includes typing into this email. Quick and dirty test program with actual data from Wireshark. Stepping through in debugger. 12:15 PM Found bug. Missing loop increment, silly mistake. 12:28 PM Passes four reasonably-useful test cases. So it took 47 minutes including writing a custom unit test. I would probably stare at it a while longer and find things I'd want to change. I would definitely look at it again the next day. QA will want to work on product tests of course. There is a non-zero probability that it still contains bugs, but I think it's a reasonable first cut. Anyone is welcome to use it if it helps. - Marsh --------------060905010508040002010208 Content-Type: text/plain; name="getExtensionData.cxx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="getExtensionData.cxx" // This example code which is quite possibly defective is placed // in the public domain by the author Marsh Ray without making any // representation that it is suitable for any purpose. #include #include #include #include // auto_ptr using namespace std; typedef std::exception MyRuntimeExceptionType; // define according to your needs // Obtains the payload of the specified extension. // Returns a null auto_ptr if the extension was not present. auto_ptr > getExtensionData( unsigned char const * const pBeginExtData, // in, first byte of extension data unsigned char const * const pEndExtData, // in, first position _after_ extension data unsigned const extType ) // in, IANA-assigned type id of extension of interest { assert(pBeginExtData && pBeginExtData < pEndExtData); assert(extType); auto_ptr > rv; // returned value for (unsigned char const * p = pBeginExtData; true; ) { size_t const cntBytesAvail = pEndExtData - p; if (cntBytesAvail == 0) break; // Cleanly reached end of extension data. else if (cntBytesAvail < 4) // A minimal extension is 4 bytes. throw MyRuntimeExceptionType(); // Bad extension data. else { // We have a plausible amount of extension data. unsigned const statedExtType = (p[0] << 8) | p[1]; p += 2; unsigned const statedExtDataLen = (p[0] << 8) | p[1]; p += 2; if (p + statedExtDataLen > pEndExtData) throw MyRuntimeExceptionType(); // Bad extension data stated length. if (statedExtType == extType) { // Hooray, we found it! rv.reset(new vector); if (statedExtDataLen > 0) rv->assign(p, p + statedExtDataLen); break; } // Advance to next extension. p += statedExtDataLen; } } return rv; } int main(int argc, char *argv[]) { int rv = -1; try { // From actual packets static unsigned char extBlock[] = { 0x00, 0x0b, 0x00, 0x04, 0x03, 0x00, 0x01, 0x02, 0x00, 0x0a, 0x00, 0x34, 0x00, 0x32, 0x00, 0x01, 0x00, 0x02, 0x00, 0x03, 0x00, 0x04, 0x00, 0x05, 0x00, 0x06, 0x00, 0x07, 0x00, 0x08, 0x00, 0x09, 0x00, 0x0a, 0x00, 0x0b, 0x00, 0x0c, 0x00, 0x0d, 0x00, 0x0e, 0x00, 0x0f, 0x00, 0x10, 0x00, 0x11, 0x00, 0x12, 0x00, 0x13, 0x00, 0x14, 0x00, 0x15, 0x00, 0x16, 0x00, 0x17, 0x00, 0x18, 0x00, 0x19, 0x00, 0x23, 0x00, 0x00 }; //---- Test case: Nonempty extension, first in list { auto_ptr > extData = getExtensionData( extBlock, // unsigned char const * const pBeginExtData, extBlock + sizeof(extBlock), // unsigned char const * const pEndExtData, 0x000b ); // unsigned const extType if (!extData.get()) throw std::runtime_error("test fail"); if (extData->size() != 4) throw std::runtime_error("test fail"); if (extData->at(0) != 0x03) throw std::runtime_error("test fail"); if (extData->at(3) != 0x02) throw std::runtime_error("test fail"); } //---- Test case: Nonempty extension not first in list { auto_ptr > extData = getExtensionData( extBlock, // unsigned char const * const pBeginExtData, extBlock + sizeof(extBlock), // unsigned char const * const pEndExtData, 0x000a ); // unsigned const extType if (!extData.get()) throw std::runtime_error("test fail"); if (extData->size() != 52) throw std::runtime_error("test fail"); if (extData->at(1) != 0x32) throw std::runtime_error("test fail"); } //---- Test case: Empty extension, last in sequence. { auto_ptr > extData = getExtensionData( extBlock, // unsigned char const * const pBeginExtData, extBlock + sizeof(extBlock), // unsigned char const * const pEndExtData, 0x0023 ); // unsigned const extType if (!extData.get()) throw std::runtime_error("test fail"); if (extData->size() != 0) throw std::runtime_error("test fail"); } //---- Test case: Extension not found. { auto_ptr > extData = getExtensionData( extBlock, // unsigned char const * const pBeginExtData, extBlock + sizeof(extBlock), // unsigned char const * const pEndExtData, 0x9999 ); // unsigned const extType if (extData.get()) throw std::runtime_error("test fail"); } rv = 0; } catch (std::exception & e) { cout << "Exception: " << e.what() << "\n"; } catch (...) { cout << "Exception.\n"; } cout << "Done.\n"; return rv; } --------------060905010508040002010208-- From marsh@extendedsubset.com Thu Dec 10 10:53: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 3AFA33A68D1 for ; Thu, 10 Dec 2009 10:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqunIx1L-o0K for ; Thu, 10 Dec 2009 10:53:40 -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 7A1743A68C8 for ; Thu, 10 Dec 2009 10:53:40 -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 1NIo8m-0008yU-Mo; Thu, 10 Dec 2009 18:53:28 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9845F603A; Thu, 10 Dec 2009 18: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/JfXVigSOrTPVh/dCBXLefnMbRCipyw+o= Message-ID: <4B2143A1.6020000@extendedsubset.com> Date: Thu, 10 Dec 2009 12:53:21 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: 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] Please be specific: RI alone, RI with MCSV, or MCSV alone X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 18:53:41 -0000 Paul Hoffman wrote: > While following the numerous threads, it seems that some people are > advocating adding MCSV to RI, while others are advocating RI by > itself (no MCSV), while others are advocating MCSV by itself (instead > of RI). > Can people please be more specific which proposal they are > advocating? It greatly affects the conversation. Thanks! I am advocating draft-ietf-tls-renegotiation which includes MCSV. I don't think anyone still is still advocating "RI without MCSV". My interpretation of draft-mrex-tls-secure-renegotiation is that it uses MCSV in Client Hello and a fixed empty extension in Server Hello. Martin may describe it differently. - Marsh From mrex@sap.com Thu Dec 10 12:10: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 ABF843A6A36 for ; Thu, 10 Dec 2009 12:10:28 -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 zkbA6hOCUQDZ for ; Thu, 10 Dec 2009 12:10: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 2F2BA3A659B for ; Thu, 10 Dec 2009 12:10:26 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBAKABp3002166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 21:10:11 +0100 (MET) From: Martin Rex Message-Id: <200912102010.nBAKAAbI002844@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 10 Dec 2009 21:10:10 +0100 (MET) In-Reply-To: <4B214209.6020304@extendedsubset.com> from "Marsh Ray" at Dec 10, 9 12:46:33 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, James@Manger.com.au Subject: Re: [TLS] How to wade through Hello extensions was: The MCSV hack is a compliment 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, 10 Dec 2009 20:10:28 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Marsh Ray wrote: > > > > > > It also requires the use of an extension. > > > > No, it does NOT. > > > > draft-mrex-tls-secure-renegotiation-03 uses additional data following > > the compression_method in ServerHello for Server->Client signaling. > > See Section 4.4 last two paragraphs of that draft. > > > > That extra data is designed to be compatible with TLS extensions, > > but it can be processed like a static 6-octet string by extensions-free > > implementations. > > Hmmm, an additional six bytes after a hello: > > 0x00 0x04 0xFF 0x01 0x00 0x00 > > I'd call that an extension. To an extension-less TLS client and TLS server this is a fixed, 6-octet piece of binary data. To extensions-aware TLS clients and TLS servers this is a single TLS extension. To avoid confusion with TLS extension RI, my openssl patch uses 0xff 0x02 (the I-D itself only contains TBD). > > The only difference is that in draft-ietf-tls-renegotiation it contains > useful payload data on renegotiation handshakes. TLS extension RI uses an _much_ more complex sematic, which has been causing the obvious confusion among implementers what to send on the renegotiation ClientHello in a backwards interop scenario, and some are actually fighting for the wrong answer. > > Hmm, let's see how long it takes me to write this in C++. In good mission-critical software, the error handling is 70-80% of the code. Your code avoids this issue for the most part. Your approach is doing what I call module testing. There should be more test vectors, in particular defective test vectors, plus checking that the error handlings works correctly (completely missing in your example). If your error handling is using C++ exceptions, that this part can _NOT_ be tested by module testing in this fashion (that would only work embedded in the actual TLS implementation that does the exceptinon processing. What you didn't count so far is all the work that is necessary to automate this testing, in particular if you want to do module testing on the code when it is part of the TLS implementation, which might include test scripts, Makefiles, new test targets, ... Btw. unconditional assert() is something that you _DEFINITELY_ do not want in mission critical software. A crash/core-dump is not permitted behaviour in productive environments. Instead, if you detect a situation that prevents you from continuing, the code should try to fail sensibly and gracefully, which means returning an error and trying to write a log/trace entry reporting the situation. If you have a server running with 200 concurrent user sessions, and there is one situation where one of your libraries gets called with a NULL object handle, you do _NOT_ want to crash the entire server, causing all 200 users to loose all their current state (including unsaved data), but instead, you report an error to the caller and write a log/trace file entry. When stuff like this happens at a customer site, it might be an indicator that the callers above your code might not have sufficient test coverage. If you need to be able to run a debugger on the customers machine in order to analyze an error a complex piece of application software, then there are some environments where you will have a hard time selling (or create a huge amount of maintenance costs). Personally, I like the "writing code" part also _much_ more than the writing TESTs part (in particular because the latter is several times more work). When you are forced to write your own tests (or take _full_ responsibility when your code breaks at the customers site), then you may start writing code in a fashion that it is easily testable, robust and failSAFE. -Martin Off-topic: using C++ for something that is a toolkit for consumption by others is a decision you will regret badly after some years on almost every Unix platform. (hints: shared libraries, dynamic runtime loading, global symbol space -- there are tons of platfrom-specific suprises waiting to be discovered). From yangsita@gmail.com Thu Dec 10 12:20: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 8F1773A68E0 for ; Thu, 10 Dec 2009 12:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.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 jpO8C0z0lHCw for ; Thu, 10 Dec 2009 12:20:50 -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 718C33A67A8 for ; Thu, 10 Dec 2009 12:20:50 -0800 (PST) Received: by bwz23 with SMTP id 23so158484bwz.29 for ; Thu, 10 Dec 2009 12:20:35 -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=Jf/upSbGaja5D0XiN6zdYoiygt/Yee5mPWzR7Smdq+E=; b=GJ9r0hN4QmxHqNwPa/XcYcgAZ4J8+lPZcWiXnE8DCsy/dowVXidFMV82hnWpkpQm7h PZfjbYsmyOIn2U+MAli810nfzdKgXP4qeVSK+5A2CvUAg/L4C4uLs01vXZc8lL9WVuJe xoGH2ukHaAevXMvZin6IQk5dzVkT8IPXHjq44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UFEaWqJDAC/qkQ14k3sMyESDjOl55FOiIiHc53AJPqNe8wd1rCS4TRyTrdAZPSlx2d shpIq1AcTDcOCh8BuR3bYvN9fE5Wt8GQOnKXL3tgDSxkM3PtyPXbYTg0BopqkVC73NfO 44OnNnJ5GUt1Xm/qOOCNlX+VkZZW0pgjhVmXA= MIME-Version: 1.0 Received: by 10.204.154.208 with SMTP id p16mr230233bkw.80.1260476435115; Thu, 10 Dec 2009 12:20:35 -0800 (PST) Date: Thu, 10 Dec 2009 21:20:35 +0100 Message-ID: <7802aa750912101220j72d873d0mda6220e2e9f406de@mail.gmail.com> From: Yang Tse To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Two drafts, two last calls ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 20:37:12 -0000 Hello, Given the fact that draft-mrex-tls-secure-renegotiation has already completed a two weeks period as an Internet-Draft, I would like to know if the IETF Security Area Director will make a Last Call on this draft, or if there are any reasons that prevents this from happening. Cheers, -- -=[Yang]=- From mrex@sap.com Thu Dec 10 13: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 E49D23A690F for ; Thu, 10 Dec 2009 13:22:59 -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 I9UIR95c+8+M for ; Thu, 10 Dec 2009 13:22: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 C7A7B3A68C4 for ; Thu, 10 Dec 2009 13:22:58 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBALMk09018219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Dec 2009 22:22:46 +0100 (MET) From: Martin Rex Message-Id: <200912102122.nBALMjVq007470@fs4113.wdf.sap.corp> Orig-To: paul.hoffman@vpnc.org (Paul Hoffman) To: tls@ietf.org Cc: tls@ietf.org Date: Thu, 10 Dec 2009 21:50:16 +0100 (MET) In-Reply-To: from "Paul Hoffman" at Dec 10, 9 10:23:50 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal05 X-SAP: out Subject: Re: [TLS] Please be specific: RI alone, RI with MCSV, or MCSV alone 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, 10 Dec 2009 21:23:00 -0000 Paul Hoffman wrote: > > While following the numerous threads, it seems that some people are > advocating adding MCSV to RI, while others are advocating RI by itself > (no MCSV), while others are advocating MCSV by itself (instead of RI). > > Can people please be more specific which proposal they are advocating? > It greatly affects the conversation. Thanks! Provided that we mean this: (1) RI by itself (no MCSV) = draft-rescorla-tls-renegotiation-00 (2) RI with MCSV = draft-ietf-tls-renegotiation-01 (3) MCSV (no RI) = draft-mrex-tls-secure-renegotiation-03 I'm firmly against (1) I prefer (3) I could live with (2) if the requirements for MSCV were tightened to be as non-disruptive as possible. I have been trying to explain what those requirements are. The overloaded semantics of TLS extension RI create special cases where some implementors have been advocating inappropriate behaviour for implementations in backwards interop scenarios. For some implementors, non-disruptive backwards interop provisions are familiar, and they _might_ get it right with as little guidance as draft-ietf-tls-renegotiation-01 currently provides if they've been following the discussion sleep over their implementation for several days and test it extensively. The discussion seems to indicate that even experienced implementers may get it wrong, and that some are much more eager to ship than to think about it and test. And if implementors need an extensions-intolerant server for testing -- that shouldn't be a problem, you can easily make one yourself; it is likely a simple 1-2 LoC change to your own code. ;-) -Martin From marsh@extendedsubset.com Thu Dec 10 14:02:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601F93A67F6 for ; Thu, 10 Dec 2009 14:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwYi+Ykb4ITH for ; Thu, 10 Dec 2009 14:02: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 D185428C11D for ; Thu, 10 Dec 2009 14:02:09 -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 1NIr5B-00024I-OW; Thu, 10 Dec 2009 22:01:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5AFA4603A; Thu, 10 Dec 2009 22:01: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: U2FsdGVkX1+R8MSjNoaMh+ecQE6oYHtipVFCA3Nu6lI= Message-ID: <4B216FD0.7060801@extendedsubset.com> Date: Thu, 10 Dec 2009 16:01:52 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912101613.nBAGD3X2016314@fs4113.wdf.sap.corp> In-Reply-To: <200912101613.nBAGD3X2016314@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] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 22:02:13 -0000 Martin Rex wrote: > Marsh Ray wrote: >> >> That is interesting information. Would you happen to have a copy of the >> last "official" spec you can send me? > > Netscape's official SSLv3 spec as of 2005: > http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM Thanks. That's pretty clear, SSLv3 did not have a provision for extending Client Hello. > As obvious from it's name that spec is a product of the TLS WG and > the TLS WG decided to completely abandon (instead of publishing as > informational RFC) that document so that it expired and vanished > from the I-D repository 6 month later. Seems like SSLv3 was simultaneously one of the most critical protocols for net security and orphaned. >> Servers receiving an initial connection request without a request for RI >> will soon know some things: >> >> 1. The client software is not patched for security. >> >> 2. There's a good chance the client is vulnerable to one or more >> variants of this basic attack. > > If that is the impression that the current draft-ietf-tls-renegotiation-01 > leaves with you, then this draft needs MAJOR updates of the description, > because it is not correct. I meant "request for RI" in the general sense which also includes MCSV. > One obvious problem with draft-ietf-tls-renegotiation-01.txt is that > is extremely underspecified. The TLS extension RI is overloaded in > semantics, and the spec doesn't spell it out. You're way overstating it. Sure, there will be a few things added to the next version. > In the original definition (without MCSV) TLS extension RI conveys > three distinct pieces of information: > > 1.) indication that the TLS peer is updated for secure renegotiation > (1 bit of information) Yes. > 2.) indication of whether the TLS peer is performing an initial > or a renegotiation handshake > (1 bit of information) > > 3.) identification of the previous TLS session the TLS peer > assumes to be renegotiating These are not separate. "The ID of the previous state on the connection" is quite naturally expressed as a zero length renegotiated_connection field. This is not overloading. > Since all of this information is carried in the same TLS extension, > a correct spec and a correct implementation is a little complex. > > Since the current document does not make this clear, the decision > what to send, in particular for backwards interop scenarios, > is non-obvious -- and obviously some people on this list, which > I believe to be experienced engineers, seem to have gotten this wrong. Oh good grief. > The reason why my proposal is actually much simpler to explain > in full detail and simpler to implement, is that it uses two > completely seperate mechanisms to convey (1) and to achieve (3) I just don't see that as a big deal. > and it doesn't do (2) at all. > (Not doing 2 means that MitM attacks > can not be distinguished from other finished MAC errors im my I-D). This is not any advantage, in fact it is a disadvantage. MitM clearly knows who's doing renegotiation and who's not. Aside from the fact that he's the one orchestrating it all, it's observable from unencrypted data on the wire. The only parties who can't determine that there is a MitM attack going on are the legitimate client and server under attack! That's bad, they would be better off if they could log or alert about that sort of thing. > For interop scenarios with old servers, and as currently used by > conservative clients and reconnect fallbacks (extension-less ClientHellos, > SSLv3 ClientHellos and SSLv2 ClientHellos), sending a TLS extension > in the initial ClientHello would be a change with a significant > disruptive potential. Not sending any indiciation of the update > for TLS renego protection leaves vulnerabilities, therefore MCSV > is used. > > From the server reply (ServerHello), the client can determine whether > it is talking to an old or an updated server--the updated Server will > return a TLS extension RI in ServerHello. > > When the client has established a TLS session with a presumably > old server, That was their first mistake. Hope they weren't using TLS for anything important. > and that server asks for renegotiation Now they know their connection is vulnerable and if they supplied a client cert it may have been forwarded. > for whatever > reason (or maybe the client wants renegotiation for client identity > protection), then TLS extension RI is of *NO* use at all. Neither is MCSV of any use with an unpatched server. What's your point? > The only thing that TLS extension RI on the renegotiation ClientHello > with an old server is interop problems. Then don't send it if you prefer interop to security. You had the chance to negotiate it interoperably on the first handshake. > But not sending anything > would make the renegotiation vulnerable to a "downgrade attack" > with an updated server. Therefore we need to use MCSV for the > renegotiation with an old server. > > MCSV will allow an updated > server in an MitM scenario to prevent a renegotiation handshake > from succeeding. > > If the updated server receives the MCSV on an initial handshake, > it will reply with an empty TLS extension RI, which will allow > the client to determine whether his renegotiation with an > presumably old server is proxied into the initial handshake > of an updated server, so the client MUST abort. You do raise an interesting case here. One which does seem to support the idea of sending MCSV on every Client Hello. There are still multiple ways that its security is broken though, so I'm hesitant to agree that it's a significant improvement. > If the updated server receives the MCSV in a renegotiation handshake, > but no accompanying TLS extension RI with the client_verify data, > then the server MUST abort the renegotiation handshake because > this is likely an updated's clients initial handshake that is > proxied into the renegotiation handshake of an updated server. This is the standard use of MCSV in every proposal I've seen. >> Clients receiving a request for renegotiation without having previously >> negotiated RI can expect that the server is vulnerable to MitM and they >> may have already been pwned on this connection state. > > The client should not try to rationalize what and what not a server > might be doing. The client should look at the handshake reply, > look at its policy/configuration and either abort the handshake > or continue. OK, I'll put it differently. A vendor, admin, or user who configures a client implementation of TLS to operate in "compatible mode" is still insecure when connecting to unpatched systems. They are making a conscious decision that interoperability with unpatched systems is more important to them obtaining the security guarantees advertised by SSL/TLS. We must not judge them for that. However, neither can we give them security on renegotiation which was not present on the initial handshake. Suggesting that we do that somehow could be quite misleading. There might be room for multiple opinions on this though. >> Servers receiving a client-initiated renegotiation without having >> previously negotiated RI can not know that it is the same party they >> have on the current connection state. > > Similarly, servers should not try to rationalize about clients, but > instead rely on policy/configuration and implement behaviour that > is mostly failsafe. > > If an updated server receives a ClientHello on a renegotiation handshake > that carries an MCSV, but lacks the TLS extension RI containing the > Client.Finished.verify_data, then that server MUST abort the handshake. Agreed, I believe that will be in the next version the draft. >> Starting soon, the absence of RI on a hello is going to be an >> increasingly strong indicator of "broken and insecure". Eventually, it >> will just be discarded along with SSLv1 and v2. > > Nope, it will be an MitM on backwards interopble clients, and many > of those clients will be updated and capable to send MCSV. I meant "request for RI" in the general sense which also includes MCSV. >>> If we do not provide provisions for smooth interop for at least the >>> transition period, it will hurt _everyone_! >> If you really want to renegotiate with old, broken, unpatched, and >> extension-intolerant servers so badly that you're willing to do it >> insecurely then don't send them the freaking extension! >> >> Sending them an MCSV is at best going to be ignored by such a server, no >> matter what semantics some document attaches to it. > > You're _not_ sending the MCSV for use by that old server, > you're including it so that this ClientHello can not be diverted/proxied > into the handshake of an updated server and result in a successful > handshake if that server is backwards interoperable. I get what you're saying now. I tend to dismiss that case because it's already fundamentally broken in multiple ways. Are there useful "degrees of brokenness" in this kind of case? It's an interesting philosophical and practical question. >> Not relevant. What matters is the number of servers that hang in a slow >> fail condition when sent an extension. > > During my tests with openssl-0.9.8l I noticed that a client sending > a renegotiation ClientHello to openssl-0.9.8l will hang. An openssl-0.9.8l > server seems to _not_ reply to this ClientHello (with a no_renegotiation > alert), but instead completely ignore the handshake message. Not good. Wasn't 0.9.8l the version patched to simply disable client-initiated renegotiation? >> Look, SSLv3 is broken. > > SSLv3 isn't broken. I think I've proven that it is. > It was just _not_ designed to be extensible. That's proving to be a big problem now. The best thing would be to just retire it, except we want to be kind and accommodating to implementors. > If you look at TLS, it is not that much better. It is infinitely better in the extensibility department. > It took them 7 years > to define extensibility. They made a spot for it from the beginning. > They could have simply added a 4-octet bitfield > for future assignment as the first piece of TLS extensions right into > the TLSv1.0 spec. If all you need to convey is a single bit of information, > then a single bit in a relatively fixed location of a handshake message > is _so_ much easier to use than the generic TLS extensions carriage. Yes, I would have probably done it that way (in addition to extensibilty via TLVs). In my experience though, no matter how well you document how certain bits should be initialized and how they should be ignored, some implementors are just going to doing wrong. This is not an argument against doing it and documenting it well, however. It just says you shouldn't have naive expectations about how smooth it will go when it comes down to it. >> Sure there is: some clients get a positive benefit from the use of >> extensions. How to manage the tradeoff between that benefit vs. >> potential interactions with intolerant servers is something app >> developers and admins/users currently manage. > > As long as there are extensions-intolerant servers still in use, > only clients that have a re-connect fallback mechanism can benefit. Three web browsers are the only clients I'm aware of that implement fallback reconnect and they would love to dump it. There are probably more. My impression is that many modern TLS clients get by just fine without catering to extension-intolerant servers. > You may ship completely new products without fallbacks, but if > you are a software vendor, you definitely can not hotfix disruptive > changes into the installed base unless it is absolutely unavoidable > and your customers are willing to accept this. > > For secure TLS renegotiation, the use of TLS extensions in a > disruptive fashion is easily and clearly avoidable. Apparently, you feel that any use of TLS extensions would be "disruptive"? > I'm sorry for that. It is not my intention to confuse. It's not necessarily you, this material is inherently difficult. >>> This requirement is about protection from MitM-attacks, it is _NOT_ >>> about successful secure renegotiations (which are not possible when >>> talking to an old server in backwards interop mode). >> Sorry, which requirement was that? > > Sending the MCSV on _every_ ClientHello (initial *AND* renegotiations). OK. There is new wording expected in the next draft. Probably something like this: vvvvvvvvvvvvvvvvv 5. Requirements for Sending and Receiving TLS clients which support this draft MUST generate either the "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST cipher suite with every ClientHello. TLS servers which support this draft MUST generate the "renegotiation_info" extension in the ServerHello in response to any client which offers either "renegotiation_info" or Client Hello TLS_RENEGO_PROTECTION_REQUEST in the ClientHello. Note that these requirements still apply even after previous handshakes of the same the connection or session did not negotiate the use of RI. Every handshake is to be treated independently in this respect. ^^^^^^^^^^^^^^^ Does this address your point? > One signaling mechanism (MCSV) to for conveying Client->Server that the > client is updated is perfectly sufficient. I have found it tricky to think in terms of "the client is this" or "the server is that", because the essence of these attacks is that MitM breaks your assumption about who you are talking to across a renegotiation. >> Patched clients and servers must validate the content of the (now >> required to be present and nonempty) RI extension received on subsequent >> Hellos. The MCSV field on subsequent Client Hellos is now redundant in >> all cases (both valid and attack). > > No, it isn't. It enables RI-minimal implemementations of old TLS servers > to detect proxied handshakes with updated MitMs. By "RI-minimal" I take you to mean "one which does not implement renegotiation". Do you have any examples of these servers which are proven to never renegotiate? > You might want to take the position, that it is the client who is > being fooled, so only the client needs to be aware of the attack, > but *I* think that would be an incomplete fix. No, I have said repeatedly that both the client and server have a critical interest in the security of the protocol. That is why I haven't spent much time thinking about scenarios where a client is willing to operate in compatible mode. >>> There is even brand new code under active maintenance without support >>> for TLS extensions. >> Well, guess what! The protocol now needs to be extended. > > No, it doesn't. It needs to be fixed! Your proposal uses an extension whether you admit it or not. Pretending that it's not only leads to partial implementations of extension handling which do things like depend on the order and number of total extensions. Maybe today in a few cases you can show that variations can't happen. It's trivial to implement correctly so there is absolutely no gain to not doing so. On the contrary, we've all seen the cost of having half-assed protocol implementations build up over time. >>> TLS extensions is purely optional, not part of the vulnerability >>> and does not need to be part of the solution. >> No one came up with any other less-impactful way to do the required S->C >> signaling, and not for lack of trying. > > Plain Wrong. My proposal works without TLS extensions, that is Baloney. > clearly explained. It just happens to use a S->C signaling scheme > that looks like TLS extensions to TLS-extensions aware implementations > and can be parsed with TLS extensions parsers, for those who prefer > to do it that way. That must be why my extension parsing code parses the example out of your document just fine. Tell me, how can I fix my extension code so that it correctly identifies your non-extension as not an extension? By that logic, "renegotiation_info" described in draft-ietf-tls-renegotiation isn't an extension either. Or is it just "extra bytes that look like TLS extensions" on Server Hello that aren't extensions? > But my draft explains clearly how to do it without TLS extensions, > and the OpenSSL patch I posted contains an extension-less implementation > of the signaling -- and the Client side of the extension-less code > is actually used for server_version==SSL3_VERSION. No, what you have is a half-baked minimally-compatible extension mechanism in denial. It only works because of the long chain of reasoning required to prove that it will never be asked to share the protocol space with real extensions. It will break as soon as someone else does the same thing, thinking they can make assumptions about number and ordering on extensions appearing on certain Hello messages. If your design can't tolerate the possibility of someone else reasoning the exact same way, it's not very good is it? Protocol designers and implementers have been through this a countless number of times. Just admit you're extending the Hello message and use the standard and interoperable mechanism like everyone else. The only global-scope coordination it requires for correctness is handled through the IANA and they seem to do a decent job of it. > Look at the last two paragraphs of Section 4.4 which describe > how extension-less clients and extension-less servers can implement > this with <10 LoC each. And my openssl-patch contains exactly > that code. It is exactly this kind of foolish false economy that has put SSL/TLS interoperability in the state it is in today. >> By the way, do you of any TLS implementations that do not "implement >> renegotiation"? > > There are two possibilities with the same effect: > Do not implement it in the fashion of "have never contained it" > and do not implement it in the fashion that it is hardwired to disabled. > > openssl-0.9.8l is one of the latter. Yes, it's an emergency patch that is not suitable for everyone. > What you currently see is a lot of customers asking for patches > that reliably disable renegotiation for the servers, because most > servers do _not_ need it. > > And once you've come to the conclusion that you don't really need > it, there is no use to implement full secure TLS renegitiation. Again, do you know of any modern, maintained TLS implementations that have decided that they do not need to ever support renegotiation? > RI-minimal would be just fine, and much easier to test and ship > as a hotfix for an old installed base. >> If you write the spec that way, the world is married to the MCSV >> forever. And we waste three bytes on every handshake. > > Cipher suite values in SSLv3/TLS are two bytes, Well it changed a while back, would be interesting to know why. > and if you're really > concerned about that, you should go for draft-mrex-tls-secure-renegotiation, > because it will need even less bytes on every handshake, in particular > on the renegotiation handshakes. No. > If TLS extension RI specifies to NOT send an empty TLS extension RI > on the initial handshake EVER, only MCSV, and additionally include > MCSV on every renegotiation handshake, then you save 3-5 bytes > on every initial handshake and pay 2 bytes extra on every > renegotiation. That means for >95% of the usage scenarios you > will save. It's not worth one bit of extra complexity to me. To me, the MCSV hack and your proposed subset of the current extension mechanism are extra complexity. > I can imagine that it takes quite some time to implement an MitM attack > on TLS renegotiation. > > I'm sorry for just thinking about it for an hour, checking the TLS spec > for flaws in my line of thought for 20 minutes and then posting it > publicly to tls@ietf.org that TLS renegotiation is susceptible > to MitM attacks. Well I did the same thing initially, but my process was to bug it internally. Not being an expert, I felt I had to prove it thoroughly before I went around making (what I saw as) extraordinary claims. >>> Have you worked for a software company with 5000+ software developers >>> during the last three years? >> No, would you like me to write the 80 LoC for you?. > > I don't have problems with writing that code. But you certainly > could help me with the weeks of paperwork and automated test-cases > necessary to get official permission to ship that change into an > installed base in maintenance mode. I suspect that your paperwork increases sub-linearly with LoC. > Some 10 LoC changes require 300+ LoC test tools. If you look at > my openssl patch, it does not create a lot of new code pathes > that can only be reached with test tools. 98% of that new > code is fully covered during regular use/interop, and works > in a failsafe fashion -- i.e. if it didn't work as designed, it > would result in interop problems. That's all good. It would certainly be simpler to just break interop with SSLv3 and broken TLSv1 servers. That's a form of fail-safe. >> So why would a legitimate server renegotiate a connection and switch >> certificates in a way that could surprise a client and be manipulated >> for evil? The renegotiation fix proves it's the same server with no >> MitM. > > It _only_ proves there is no MitM acting without consent of that > server. There's no such thing as an attack with the consent of the server. The server can do anything he wants without involving the complexity of a 3rd party MitM. > If that server changes his certificate during renegotiation, > it is DEFINITELY not the same server as before. If that were the case, you would be unable to say "server changes his certificate". "Server" is an increasingly nebulous term, what with shared IP load balancing, "cloud", "ssl offload", and all. Here's what one relevant RFC says it is: > The server is the application entity that responds to requests for > connections from clients. See also under client. I wouldn't go around saying it "DEFINITELY" is this or that. > Depending on what > the new cert looks like, the client may accept this change, but > the assumption that a client must not care is flawed, and can > by itself become a security problem for some situations. > > If you're doing security-related stuff, it is extremely important > that you are staying clean at the abstract level. Some of the > risks that one creates by sloppiness at the abstract level may > lead to mostly theoretical vulnerabilities (like adding arbitrary > data to the handshake message hash instead of handshake messages), > and sometimes it can create very practical risks (like ignoring > identity changes). I'm saying you have some unsubstantiated assumptions and "unclean abstractions". > There are some apps on top of TLS that "tie" certs to hostnames, but > as previously discussed, that is entirely an apps issue, and the > TLS implementation can _NOT_ force re-authentication on the application > caller! Until the SNI extension can be made mandatory, in practice a TLS server can't present different server certs from the same IP and port. That's all I was saying. > In the IETF security area we try to avoid this kind of approach: > worrying about vulnerabilities only when exploits have been published. I'm saying it's probably not a protocol vulnerability if it was a documented feature of the protocol. There need to be seriously good reasons before removing functionality in a protocol spec. That a few knowledgeable people have found it surprising on first glance is relevant, but not persuasive. Finding an actual system that misinterpreted the spec and plausibly had a vulnerability would be even more useful. Finding many systems which were vulnerable to having made the same mistake interpreting the spec would make it worth considering removing or restricting the protocol feature. But so far nobody has described even a hypothetical (but plausible) example. > We want to move away from MD5 in online authentication even though > nobody has demonstrated real-time second preimage attacks against MD5 yet. You'd better be looking to move away from SHA-1 as well. >>> A client that has not been previously >>> authenticated performs a client cert authentication. That is a >>> highlander operation. >> I'm not familiar with that term. Searching for it results in some NSA >> wiretapping gone wrong. >> http://www.wired.com/threatlevel/2008/10/kinne/ > > You mean the term "highlander"? > > Look here: http://en.wikipedia.org/wiki/Highlander_%28film%29 OK, I remember hearing about that movie/TV show. I didn't watch it. > "in the end, there can be only one." Only in your preconceptions. It's not in any TLS protocol spec I've seen. > To have more than one client cert listed for an authenticated TLS session > would be a pretty dumb idea. Just because you can't imagine how it might be useful doesn't make it a dumb idea. > There are platforms that offer such mechanisms more like a feature > of the "Trusted Computing Base", which allows to pass of ACL checks > in a Posix-ACL style to the underlying OS (ImpersonateSecurityContext()). > > These functions would likely have difficulties dealing with a set-of > instead of a single client identity, and they would be faced with the > problem that Access Control and auditing/audit logs can deal only > with a single Access Token (identity). So what? >>> The secure renegotiation is provided by "authenticating" the verify >>> data from the previous finished messages. >> I wouldn't describe it that way. It's just checking that two values are >> in agreement. These values were authenticated by the previous handshake >> process. > > That is what is supposed to happen. I know that TLS extension RI > uses an unconventional way to perform this authentication -- it Which is why I wouldn't describe it as authentication. > exchanges the data in an integrity-protected fashion and needs to > memcmp() the contents. Which is why TLS extension RI is not failSAFE. Where fail = crypto code is buggy. It's probably not what any of us would designed if we could do it from a clean sheet, but we don't have that option. On balance, I think it's an effective fix and is the most deployable on an urgent basis. - Marsh From marsh@extendedsubset.com Thu Dec 10 14: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 B312C3A692E for ; Thu, 10 Dec 2009 14:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drgTC4HjyQnr for ; Thu, 10 Dec 2009 14:57:48 -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 B44683A6866 for ; Thu, 10 Dec 2009 14:57:48 -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 1NIrx2-0003zl-SO; Thu, 10 Dec 2009 22:57:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 83D43603A; Thu, 10 Dec 2009 22:57: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: U2FsdGVkX1/1l0suk57ZLZoJvOSrHIDE54oZ/+DSUqk= Message-ID: <4B217CDB.9050502@extendedsubset.com> Date: Thu, 10 Dec 2009 16:57:31 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912102010.nBAKAAbI002844@fs4113.wdf.sap.corp> In-Reply-To: <200912102010.nBAKAAbI002844@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] How to wade through Hello extensions was: The MCSV hack is a compliment X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 22:57:49 -0000 Martin Rex wrote: > > To an extension-less TLS client and TLS server this is a fixed, 6-octet > piece of binary data. Until someone else wants that space for their own "fixed piece of binary data". > In good mission-critical software, the error handling is 70-80% of > the code. Your code avoids this issue for the most part. My code throws an exception when it determines the input is invalid or memory allocation fails. It's standard C++ stuff and works pretty well in my experience. A full C++ TLS implementation would probably have its own type for reporting protocol errors. It would probably already have error handling code with an exception-based interface. > Your approach is doing what I call module testing. > There should be more test vectors, in particular defective > test vectors, plus checking that the error handlings works > correctly (completely missing in your example). > > If your error handling is using C++ exceptions, that this part > can _NOT_ be tested by module testing in this fashion (that would > only work embedded in the actual TLS implementation that does > the exceptinon processing. Sure, but it should fit easily with the established model. > What you didn't count so far is all the work that is necessary to > automate this testing, in particular if you want to do module > testing on the code when it is part of the TLS implementation, > which might include test scripts, Makefiles, new test targets, ... > > > Btw. unconditional assert() is something that you _DEFINITELY_ do not > want in mission critical software. That's why production releases are compiled with #define NDEBUG. > A crash/core-dump is not > permitted behaviour in productive environments. Instead, if > you detect a situation that prevents you from continuing, > the code should try to fail sensibly and gracefully, which means > returning an error and trying to write a log/trace entry reporting > the situation. No it doesn't "mean" that. Exceptions are superior to returning errors, in part because they are fail-safe. In any case this stuff is regularly discussed to death on comp.lang.c++ and other lists. > If you have a server running with 200 concurrent user sessions, > and there is one situation where one of your libraries gets > called with a NULL object handle, you do _NOT_ want to crash > the entire server, causing all 200 users to loose all their > current state (including unsaved data), but instead, you > report an error to the caller and write a log/trace file entry. What does this have to do with anything? Did you find a crash bug in my code? > When stuff like this happens at a customer site, it might be an > indicator that the callers above your code might not have sufficient > test coverage. > > If you need to be able to run a debugger on the customers machine > in order to analyze an error a complex piece of application software, > then there are some environments where you will have a hard time > selling (or create a huge amount of maintenance costs). > > Personally, I like the "writing code" part also _much_ more > than the writing TESTs part (in particular because the latter > is several times more work). When you are forced to write > your own tests (or take _full_ responsibility when your code > breaks at the customers site), then you may start writing code > in a fashion that it is easily testable, robust and failSAFE. > > -Martin > > Off-topic: using C++ for something that is a toolkit for consumption > by others is a decision you will regret badly after some years on > almost every Unix platform. (hints: shared libraries, dynamic runtime > loading, global symbol space -- there are tons of platfrom-specific > suprises waiting to be discovered). LOL. Dude, you don't have to use my C++ if you don't want it. I've certainly had some regrets on the *nix side over the years but C++ has never been one of them. - Marsh From mickgray@au1.ibm.com Thu Dec 10 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 E916A3A6866 for ; Thu, 10 Dec 2009 15:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.593 X-Spam-Level: X-Spam-Status: No, score=-6.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 9LF1pXjYeSIf for ; Thu, 10 Dec 2009 15:47:21 -0800 (PST) Received: from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141]) by core3.amsl.com (Postfix) with ESMTP id 956DA3A67C1 for ; Thu, 10 Dec 2009 15:47:20 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp08.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBBAl7iq001135 for ; Fri, 11 Dec 2009 21:47:07 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBANhH391589502 for ; Fri, 11 Dec 2009 10:43:17 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBANl7ax014140 for ; Fri, 11 Dec 2009 10:47:07 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBANl7ga014137; Fri, 11 Dec 2009 10:47:07 +1100 In-Reply-To: To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Fri, 11 Dec 2009 09:46:48 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 11/12/2009 10:54:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Please be specific: RI alone, RI with MCSV, or MCSV alone X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2009 23:47:26 -0000 Paul Hoffman wrote: > While following the numerous threads, it seems that some people are > advocating adding MCSV to RI, while others are advocating RI by > itself (no MCSV), while others are advocating MCSV by itself (instead of RI). > > Can people please be more specific which proposal they are > advocating? It greatly affects the conversation. Thanks! I strongly prefer: MCSV by itself (instead of RI) Additionally I prefer draft-mrex-tls-secure-renegotiation-03 over draft-ietf-tls-renegotiation-01. - Mick Gray - IBM > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From rrelyea@redhat.com Thu Dec 10 16:13: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 DBAB13A6997 for ; Thu, 10 Dec 2009 16:13:50 -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 LdU6A8T6F-yQ for ; Thu, 10 Dec 2009 16:13:49 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id AA3023A698C for ; Thu, 10 Dec 2009 16:13:49 -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 nBB0DbID011413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Dec 2009 19:13:38 -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 nBB0Da9i030794; Thu, 10 Dec 2009 19:13:37 -0500 Message-ID: <4B218EB1.8070303@REDHAT.COM> Date: Thu, 10 Dec 2009 16:13:37 -0800 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090309070204080606040701" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21 Cc: tls@ietf.org Subject: Re: [TLS] Please be specific: RI alone, RI with MCSV, or MCSV alone X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 00:13:51 -0000 This is a cryptographically signed message in MIME format. --------------ms090309070204080606040701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/10/2009 10:23 AM, Paul Hoffman wrote: > While following the numerous threads, it seems that some people are adv= ocating adding MCSV to RI, while others are advocating RI by itself (no M= CSV), while others are advocating MCSV by itself (instead of RI). > =20 I prefer RI alone, but I'm ok with MCSV with RI. I'm absolutely against MCSV alone. bob --------------ms090309070204080606040701 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 MTIxMTAwMTMzN1owIwYJKoZIhvcNAQkEMRYEFOA6mW5l6+atRP1oUaOhi6EuXre2MF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAMWZdKRfuA1E+T5/iNvgeR7IOH5XLpb7u5WTX22kgen64NGnZekY QGDIH4w2VHNCyJRcMp/NV1KS6o/AtG5XnF8N9QEG2u50qhw/7Yfm5SxIaO0JpXyPokI4VxlJ 7qwftldQhI1dzSzl2Gfv7Y8TKFQopuS7bW+6TdNufBUugrXsVyerAslETWyq5yCt1F8Ir+UD 2JOApPWMcnakGwwfliwB+0bwWZohDTQEQRGt3U43v1IColfZrI323zgNu7wWfKh6uTV/FtA9 031GoZDoEmIAi52+UeFBifxafQUOiW7C+OQpJCLZ47Grhfg3ZRyRQVq2L1+IbV5TMwriaeWg u5wAAAAAAAA= --------------ms090309070204080606040701-- From mrex@sap.com Thu Dec 10 16:50: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 608013A683D for ; Thu, 10 Dec 2009 16:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.777 X-Spam-Level: X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=-0.361, 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 vLKvl6OybvQF for ; Thu, 10 Dec 2009 16:50: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 869DF3A680E for ; Thu, 10 Dec 2009 16:50:12 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBB0nvO1007686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 01:49:57 +0100 (MET) From: Martin Rex Message-Id: <200912110049.nBB0ntj4020176@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 11 Dec 2009 01:49:55 +0100 (MET) In-Reply-To: <4B216FD0.7060801@extendedsubset.com> from "Marsh Ray" at Dec 10, 9 04:01: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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 11 Dec 2009 00:50:15 -0000 Marsh Ray wrote: > > > and it doesn't do (2) at all. > > (Not doing 2 means that MitM attacks > > can not be distinguished from other finished MAC errors im my I-D). > > This is not any advantage, in fact it is a disadvantage. Primarily at first look. It is a characteristic of the TLS handshake that tampering with the handshake will result in a Finished MAC failure and maybe the optional CertificateVerify verification failure. It would be helpful when those who are vulnerable would log attacks, but unfortunately, they don't (can't). For those who are _not_ vulnerable, that information is no longer this much different from other tampering with the TLS handshake messages. In recent years several previously distinct error situations were re-specified to make the finished MAC fail rather to point to an implementiation bug with a distinct Alert message (wrong protocol version in rsa premaster secret is one of those). > > >> Clients receiving a request for renegotiation without having previously > >> negotiated RI can expect that the server is vulnerable to MitM and they > >> may have already been pwned on this connection state. > > > > The client should not try to rationalize what and what not a server > > might be doing. The client should look at the handshake reply, > > look at its policy/configuration and either abort the handshake > > or continue. > > OK, I'll put it differently. > > A vendor, admin, or user who configures a client implementation of TLS > to operate in "compatible mode" is still insecure when connecting to > unpatched systems. Only if one of them (or both) allow old _renegotiation_. Most "interesting" scenarios that users/consumers worry about currently require the server to be the one offering old renegotiation. > > >> Sending them an MCSV is at best going to be ignored by such a server, no > >> matter what semantics some document attaches to it. > > > > You're _not_ sending the MCSV for use by that old server, > > you're including it so that this ClientHello can not be diverted/proxied > > into the handshake of an updated server and result in a successful > > handshake if that server is backwards interoperable. > > I get what you're saying now. I tend to dismiss that case because it's > already fundamentally broken in multiple ways. > > Are there useful "degrees of brokenness" in this kind of case? It is a _possible_ scenario. My proposal fixes all possible scenarios, and does _NOT_ need to iterate them. If you have to iterate through scenarios, then your solution is more complex than necessary. > > > During my tests with openssl-0.9.8l I noticed that a client sending > > a renegotiation ClientHello to openssl-0.9.8l will hang. An openssl-0.9.8l > > server seems to _not_ reply to this ClientHello (with a no_renegotiation > > alert), but instead completely ignore the handshake message. Not good. > > Wasn't 0.9.8l the version patched to simply disable client-initiated > renegotiation? I'm not sure. To me it looks like it disables renegotiation in general. Although it tests for a flag value in the session flags, there is only a control-function to retrieve that flags value, but the function to set these flags seems to be missing. The problem is that openssl-0.9.8l fails to return an SSL alert. So the client who has sent a ClientHello is waiting for a ServerHello, and the server also seems to get stuck (s_server and s_client). > > > It was just _not_ designed to be extensible. > > That's proving to be a big problem now. The best thing would be to just > retire it, except we want to be kind and accommodating to implementors. SSLv3 was the enabling technology for TLS. Sounds like murdering your parents silently and collecting their pension. The ethical behaviour is to wait until it dies of age all by itself. > > > If you look at TLS, it is not that much better. > > It is infinitely better in the extensibility department. > > > It took them 7 years > > to define extensibility. > > They made a spot for it from the beginning. Nope, that beginning was in November 1996. TLS WG decided to leave forward extensibility an unused and untested protocol feature for several years. There would not be any broken TLSv1.0 servers if that protocol feature had been appropriately tested. > > In my experience though, no matter how well you document how certain > bits should be initialized and how they should be ignored, some > implementors are just going to doing wrong. Documenting it is insufficient. The three most important things that you need is Testing, Testing and Testing. You need that to check a spec for consistency, and you need that to check implementations for interoperability and compliance. And writing good test tools can be more work than implementing the technology itself. > > > As long as there are extensions-intolerant servers still in use, > > only clients that have a re-connect fallback mechanism can benefit. > > Three web browsers are the only clients I'm aware of that implement > fallback reconnect and they would love to dump it. There are probably more. > > My impression is that many modern TLS clients get by just fine without > catering to extension-intolerant servers. Many modern TLS clients get by just fine without sending TLS extensions. But we're not talking about what the fix means for "modern" clients. We're talking about what this fix means for "old" clients and servers, which outnumber the "modern" clients by a factor of at least 50x (probably 500x if you count all the individual codelines under maintenance). > > > For secure TLS renegotiation, the use of TLS extensions in a > > disruptive fashion is easily and clearly avoidable. > > Apparently, you feel that any use of TLS extensions would be "disruptive"? Yup, definitely. For a large amount of the installed base it will would be a backwards incompatible change with *known* interop problems to suddenly have clients send TLS extensions. And a lot of software vendors can not afford to put a change with such a disruptive potential into a hotfix for the installed base. > > vvvvvvvvvvvvvvvvv > 5. Requirements for Sending and Receiving > > TLS clients which support this draft MUST generate either the > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > cipher suite with every ClientHello. > > TLS servers which support this draft MUST generate the > "renegotiation_info" extension in the ServerHello in response to any > client which offers either "renegotiation_info" or Client Hello > TLS_RENEGO_PROTECTION_REQUEST in the ClientHello. > > Note that these requirements still apply even after previous handshakes > of the same the connection or session did not negotiate the use of RI. > Every handshake is to be treated independently in this respect. > ^^^^^^^^^^^^^^^ > > Does this address your point? No, unfortunately not. Conforming TLS clients MUST include the TLS_RENEGO_PROTECTION_REQUEST on _every_ ClientHello they send. TLS clients SHOULD NOT include an empty TLS extension RI in a ClientHello. TLS clients MUST NOT send an renegotiation_info extension containing Client.Finished.verify_data in a renegotiation ClientHello in backwards interoperability situations when (a) old renegotiation is permitted and (b) no TLS extensions had been sent in the ClientHello that established the enclosing TLS session. > > > One signaling mechanism (MCSV) to for conveying Client->Server that the > > client is updated is perfectly sufficient. > > I have found it tricky to think in terms of "the client is this" or "the > server is that", because the essence of these attacks is that MitM > breaks your assumption about who you are talking to across a renegotiation. I'm sorry, I can not follow at the moment. The MitM attack has no influence on whether you are client or server. > >> Patched clients and servers must validate the content of the (now > >> required to be present and nonempty) RI extension received on subsequent > >> Hellos. The MCSV field on subsequent Client Hellos is now redundant in > >> all cases (both valid and attack). > > > > No, it isn't. It enables RI-minimal implemementations of old TLS servers > > to detect proxied handshakes with updated MitMs. > > By "RI-minimal" I take you to mean "one which does not implement > renegotiation". > > Do you have any examples of these servers which are proven to never > renegotiate? Proven to not need it? All of the servers that we shipped so far. Proven to not accidentally provide it. Less than the previous. > > Your proposal uses an extension whether you admit it or not. I admit that what my proposal uses is fully compatible with TLS extensions. You may remeber that I do care for all existing usage scenarios. That includes scenarios that use TLS extensions today. Therefore I insisted when adding anything into ServerHello behind compression_method that it be gentle to real TLS extensions that may need to get stuffed there. For simplicity, I even refer to this signal as a TLS extension in my document. It is just sufficiently simple that it not more complicated to implement than re-purposing a bit from server_version or compression_method -- for those old or constrained implementations that do not have any TLS extensions code. > > On the contrary, we've all seen the cost of having half-assed protocol > implementations build up over time. I'm sorry that I'm more worried about hundreds of old implementations that _only_ need to get fixed, by maintenance persons who are sometimes just vaguely familiar with the code, rather than the two dozen modern full-fledged TLS implementations where the maintainers are in best training, constantly experimenting with the newest features and no installed base to worry about. My approach is conservative and pragmatic. > > > But my draft explains clearly how to do it without TLS extensions, > > and the OpenSSL patch I posted contains an extension-less implementation > > of the signaling -- and the Client side of the extension-less code > > is actually used for server_version==SSL3_VERSION. > > No, what you have is a half-baked minimally-compatible extension > mechanism in denial. > > It only works because of the long chain of reasoning required to prove > that it will never be asked to share the protocol space with real > extensions. > > It will break as soon as someone else does the same thing, thinking they > can make assumptions about number and ordering on extensions appearing > on certain Hello messages. If your design can't tolerate the possibility > of someone else reasoning the exact same way, it's not very good is it? My design can tolerate that perfectly well. If you need more than one extension to be carried, you'll have to implement TLS extensions, that is obvious. If that extra data in those other situations is not compatible with TLS extensions, then that other data is a half-assed protocol extension, and it wouldn't fly with TLS extension RI either. I never claimed that my approach was perfect. I only claimed it was less complex than TLS extension RI, less code to implement, less testing necessary and highly interoperable with installed base. > > Just admit you're extending the Hello message and use the standard and > interoperable mechanism like everyone else. The only global-scope > coordination it requires for correctness is handled through the IANA and > they seem to do a decent job of it. I admit that I'm extending ServerHello with a TLS extension for everyone that implements TLS extensions, that should be rather obvious from "4.4 New protocol elements" and "6. IANA considerations". For extension-less implementations, it's a simple 6-octet binary appendix to ServerHello that is used for Server->Client signaling and trivial to implement, this is what the last two paragraphs of section "4.4 New protocol elements" describe. What it is therefore depends on your point of view. UTF8 can be interpreted as Unicode for Unicode-aware applications, can be interpreted as US-ASCII for applications that only store US-ASCII characters in there, and can be treated like traditional 0-terminated strings by string-functions of ANSI/ISO-C (c89). > > > Look at the last two paragraphs of Section 4.4 which describe > > how extension-less clients and extension-less servers can implement > > this with <10 LoC each. And my openssl-patch contains exactly > > that code. > > It is exactly this kind of foolish false economy that has put SSL/TLS > interoperability in the state it is in today. Nope. It is the lack of testing! If those guys who developed TLSv1.0 had spent their time on developing test suites and getting the installed base fixed while that software was still under maintance, or had performed a security review on the design of the renegotiation, then we would not be in the current situation, having to patch 14 years back into the past. Many protocols in the IETF have seen a huge feature creep over the past 10 years, meaning that the recycled the IETF process at "proposed" with several revisions instead of fixing the defects in the specs, getting the implmenentations to interoperate on all specified protocol features and advancing the protocol to draft standard. TLS is definitely one of those. > > > If TLS extension RI specifies to NOT send an empty TLS extension RI > > on the initial handshake EVER, only MCSV, and additionally include > > MCSV on every renegotiation handshake, then you save 3-5 bytes > > on every initial handshake and pay 2 bytes extra on every > > renegotiation. That means for >95% of the usage scenarios you > > will save. > > It's not worth one bit of extra complexity to me. > > To me, the MCSV hack and your proposed subset of the current extension > mechanism are extra complexity. Having MCSV adds complexity. Mandating its use actually reduces complexity--you don't need a conditional for adding it -- that obviates an extra test case. > > > I can imagine that it takes quite some time to implement an MitM attack > > on TLS renegotiation. > > > > I'm sorry for just thinking about it for an hour, checking the TLS spec > > for flaws in my line of thought for 20 minutes and then posting it > > publicly to tls@ietf.org that TLS renegotiation is susceptible > > to MitM attacks. > > Well I did the same thing initially, but my process was to bug it > internally. Not being an expert, I felt I had to prove it thoroughly > before I went around making (what I saw as) extraordinary claims. > > >>> Have you worked for a software company with 5000+ software developers > >>> during the last three years? > >> No, would you like me to write the 80 LoC for you?. > > > > I don't have problems with writing that code. But you certainly > > could help me with the weeks of paperwork and automated test-cases > > necessary to get official permission to ship that change into an > > installed base in maintenance mode. > > I suspect that your paperwork increases sub-linearly with LoC. The paperwork is linear with the number of additional test cases for each new code path. This is why I prefer to _not_ add new code pathes, but instead only modify existing code pathes -- in which case the existing test cases cover the changed functionality already. How may test cases do you need to verify the implementation of a secure hash functions? Very few. A few test vectors and some invalid input parameter calls are sufficient. It is extremely unlikely to get a correct results for a certain amount of test vectors by "accident". A kind of implicit fail-safe design. > > > Some 10 LoC changes require 300+ LoC test tools. If you look at > > my openssl patch, it does not create a lot of new code pathes > > that can only be reached with test tools. 98% of that new > > code is fully covered during regular use/interop, and works > > in a failsafe fashion -- i.e. if it didn't work as designed, it > > would result in interop problems. > > That's all good. > > It would certainly be simpler to just break interop with SSLv3 and > broken TLSv1 servers. That's a form of fail-safe. I don't have a problem if you do _not_ add backwards interop into your implementation. I will leave that to "market pressure". However I do have a problem if you insist on a spec that makes backwards interop difficult for _me_, because I'm paid to provide that interoperability for the installed base. > > > There are some apps on top of TLS that "tie" certs to hostnames, but > > as previously discussed, that is entirely an apps issue, and the > > TLS implementation can _NOT_ force re-authentication on the application > > caller! > > Until the SNI extension can be made mandatory, in practice a TLS server > can't present different server certs from the same IP and port. That's > all I was saying. I looked at the SNI spec, and that thing is a big mess! It appears to be an completely out-of-sync proposal. The first thing that should have been done is define a standard how to perform server authentication. One could have used rfc-2818 (HTTP over TLS, informational), which itself refers to PKIX X.509 subjectAltName dNSName and iPAddress. dNSName is an IA5String iPAddress is an OctetString, but there are canonical string representations in some specs. The hostname in SNI is defined as UTF8String which looks pretty weird! The client should send exactly that canonical hostname that it will use to verify the ServerCertificate. In order to implement SNI correctly, a TLS implementation will _now_ need to implement transforms of UTF8Hostnames into the thing that you find in Server Certificates -- which could have been completely avoided, since the client MUST ALSO implement this, and could have been passing the _result_ of this operation to the server instead! There's simple rule that says: If you have one clock, you are pretty confident to know which time it is. If you have two clocks, you are unsure. The SNI design looks like poor engineering to me. And explicitly prohibiting literal iPAddresses in rfc3546 without _ANY_ kind of justification while their use in rfc2818 is explicitly permitted for HTTP over TLS seems also a little strange/inconclusive. > > In the IETF security area we try to avoid this kind of approach: > > worrying about vulnerabilities only when exploits have been published. > > > > We want to move away from MD5 in online authentication even though > > nobody has demonstrated real-time second preimage attacks against MD5 yet. > > You'd better be looking to move away from SHA-1 as well. We can not drop SHA-1 that easily. First we must upgrade the installed base to support something better than SHA-1, then we must migrate the users to use that better-than-SHA-1 hash, and then we can think about disabling SHA-1 support. > >>> A client that has not been previously authenticated performs a > >>> client cert authentication. That is a highlander operation. > > > > You mean the term "highlander"? > > > > Look here: http://en.wikipedia.org/wiki/Highlander_%28film%29 > > > > "in the end, there can be only one." > > Only in your preconceptions. It's not in any TLS protocol spec I've seen. On the contrary, it is in all of the specs. Each peer in the TLS handshake can send at most one Certificate handshake message within one handshake. This is probably why none of the implementations I know uses an aggregate set of certificates of TLS peers. And as we all know by now, TLS renegotiation results in an entirely independent session. :-/ So you can not claim that TLS renegotiation supports a change in the identity. TLS renegotiation has been a completely new and independent handshake all the time. -Martin From nelson@bolyard.me Thu Dec 10 17:07: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 4FAE73A686C for ; Thu, 10 Dec 2009 17:07:25 -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 2yL5JnKA-zmZ for ; Thu, 10 Dec 2009 17:07:24 -0800 (PST) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id 7458C3A67BD for ; Thu, 10 Dec 2009 17:07:24 -0800 (PST) Received: (qmail 23127 invoked from network); 11 Dec 2009 01:07:12 -0000 Received: from unknown (24.5.142.42) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 11 Dec 2009 01:07:12 -0000 Message-ID: <4B219B41.3040107@bolyard.me> Date: Thu, 10 Dec 2009 17:07:13 -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: <4B218EB1.8070303@REDHAT.COM> In-Reply-To: <4B218EB1.8070303@REDHAT.COM> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Please be specific: RI alone, RI with MCSV, or MCSV alone X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 01:07:25 -0000 On 2009-12-10 16:13 PST, Robert Relyea wrote: > On 12/10/2009 10:23 AM, Paul Hoffman wrote: >> While following the numerous threads, it seems that some people are >> advocating adding MCSV to RI, while others are advocating RI by itself >> (no MCSV), while others are advocating MCSV by itself (instead of RI). >> > I prefer RI alone, but I'm ok with MCSV with RI. > > I'm absolutely against MCSV alone. Ditto. Furthermore, I would say that MCSV should be used ONLY by clients that are willing to speak SSL 3.0 or 3.1 if the server negotiates that. A client that is only willing to speak SSL 3.2 (TLS 1.1) or later need not bother with MCSV. From mrex@sap.com Thu Dec 10 17: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 027163A68E4 for ; Thu, 10 Dec 2009 17:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 m1XPD8K8L5TK for ; Thu, 10 Dec 2009 17:49:37 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 07BDC3A680D for ; Thu, 10 Dec 2009 17:49:36 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBB1nO7J009971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 02:49:24 +0100 (MET) From: Martin Rex Message-Id: <200912110149.nBB1nNfv023817@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 11 Dec 2009 02:49:23 +0100 (MET) In-Reply-To: <20091207222058.GQ861@Sun.COM> from "Nicolas Williams" at Dec 7, 9 04:20: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] Defining "TLS channel" 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, 11 Dec 2009 01:49:38 -0000 Nicolas Williams wrote: > > Note that the identity information is only relevant to the > tls-server-end-point channel binding type, and then only the server's > certificate is relevant. If the initial connection used an anon DH > cipher suite then there will be no tls-server-end-point channel bindings > data for that channel. Which would make inappropriate to talk of channel bindings for secure TLS renegotiation, because secure TLS renegotiation _will_ apply to TLS sessions established with anon DH cipher suites as well. -Martin From mrex@sap.com Thu Dec 10 18: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 8A5FF3A6897 for ; Thu, 10 Dec 2009 18:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 8EQ1KnHtrHMj for ; Thu, 10 Dec 2009 18:08: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 896753A6803 for ; Thu, 10 Dec 2009 18:08:47 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBB28TLt027749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 03:08:29 +0100 (MET) From: Martin Rex Message-Id: <200912110208.nBB28SIT024876@fs4113.wdf.sap.corp> To: mickgray@au1.ibm.com (Michael Gray) Date: Fri, 11 Dec 2009 03:08:28 +0100 (MET) In-Reply-To: from "Michael Gray" at Dec 10, 9 12:16:24 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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 11 Dec 2009 02:08:48 -0000 Michael Gray wrote: > > > in order to reliably provide this, > > > > - MCSV is defined to represent an empty TLS extension RI > > > > - MSCV MUST be included in *ALL* initial ClientHello handshakes > > messages _plus_ all renegotiation ClientHellos in backwards > > interop scenarios (independent of full handshake or session resume). > > > > - empty TLS extension RI MUST NOT be sent, ever! > > This looks good to me, the only thing I would change is I think MUST NOT > would be better as SHOULD NOT as the later requires that the implementer > examine the conditions and implications etc to make the best decision. You are right. I'm sorry. I got a little carried away. A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate. -Martin From nelson@bolyard.me Thu Dec 10 18: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 44CFC3A6897 for ; Thu, 10 Dec 2009 18:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOXyn4GDehE1 for ; Thu, 10 Dec 2009 18:23:05 -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 7D47B3A6843 for ; Thu, 10 Dec 2009 18:23:05 -0800 (PST) Received: (qmail 4195 invoked from network); 11 Dec 2009 02:22:52 -0000 Received: from unknown (24.5.142.42) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 11 Dec 2009 02:22:52 -0000 Message-ID: <4B21ACFD.8010701@bolyard.me> Date: Thu, 10 Dec 2009 18:22: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: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 02:23:06 -0000 On 2009-12-09 18:16 PST, Michael Gray wrote: > Given this large test impact I find the > draft-mrex-tls-secure-renegotiation-03 alternate solution (which does not > require full extension implementation) to be preferable. Of course, neither does draft-ietf-tls-renegotiation-01.txt require full extension implementation, so the absence of that requirements is not a basis for preference of one over the other. From nelson@bolyard.me Thu Dec 10 18:39: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 09AA13A68D6 for ; Thu, 10 Dec 2009 18:39:50 -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 n6q7ehAEu09L for ; Thu, 10 Dec 2009 18:39:49 -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 3233C3A68C1 for ; Thu, 10 Dec 2009 18:39:49 -0800 (PST) Received: (qmail 7457 invoked from network); 11 Dec 2009 02:39:36 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 11 Dec 2009 02:39:35 -0000 Message-ID: <4B21B0E8.1080702@bolyard.me> Date: Thu, 10 Dec 2009 18:39: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: tls@ietf.org References: <200912101613.nBAGD3X2016314@fs4113.wdf.sap.corp> <4B216FD0.7060801@extendedsubset.com> In-Reply-To: <4B216FD0.7060801@extendedsubset.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 02:39:50 -0000 On 2009-12-10 14:01 PST, Marsh Ray wrote: > Martin Rex wrote: >> Marsh Ray wrote: >>> That is interesting information. Would you happen to have a copy of the >>> last "official" spec you can send me? >> Netscape's official SSLv3 spec as of 2005: >> http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM > > Thanks. > > That's pretty clear, SSLv3 did not have a provision for extending Client > Hello. > >> As obvious from it's name that spec is a product of the TLS WG and >> the TLS WG decided to completely abandon (instead of publishing as >> informational RFC) that document so that it expired and vanished >> from the I-D repository 6 month later. > > Seems like SSLv3 was simultaneously one of the most critical protocols > for net security and orphaned. Stop right there. Don't be led down the garden path. Look at the parent page. Look at http://web.archive.org/web/20050205162914/wp.netscape.com/eng/ssl3/ It clearly says that "The most recent Draft SSL 3.0 specification, an Internet Draft dated November 1996, may be viewed here. It is an ASCII document". It is a link to http://wp.netscape.com/eng/ssl3/draft302.txt which is draft-freier-ssl-version3-02.txt, now seen at http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt That parent page also says: "The previous draft of the SSL 3.0 Specification, dated March 1996, may be viewed in this HTML document." which is a link to http://web.archive.org/web/20050206124632/wp.netscape.com/eng/ssl3/ssl-toc.html which in turn has a link to the page Martin cited above. You'll find my name in some of those pages, too. Don't let a non-Netscape person tell you what was, and what was not "official" at Netscape. Netscape never orphaned 3.0. It kept the "most recent draft" alive for the rest of its days, and is still kept alive today at Mozilla.org, which runs NSS code which is a direct descendant of Netscape's original code. From mrex@sap.com Thu Dec 10 18:55: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 3A61B3A6909 for ; Thu, 10 Dec 2009 18:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 h3hhEI-Mq7j0 for ; Thu, 10 Dec 2009 18:55: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 DAD983A6862 for ; Thu, 10 Dec 2009 18:55:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBB2tFin027139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 03:55:15 +0100 (MET) From: Martin Rex Message-Id: <200912110255.nBB2tE1V027686@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 11 Dec 2009 03:55:14 +0100 (MET) In-Reply-To: <4B21B0E8.1080702@bolyard.me> from "Nelson B Bolyard" at Dec 10, 9 06:39: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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 11 Dec 2009 02:55:32 -0000 Nelson B Bolyard wrote: > > >>> That is interesting information. Would you happen to have a copy of the > >>> last "official" spec you can send me? > >> Netscape's official SSLv3 spec as of 2005: > >> http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM > > > > That's pretty clear, SSLv3 did not have a provision for extending Client > > Hello. > > > >> As obvious from it's name that spec is a product of the TLS WG and > >> the TLS WG decided to completely abandon (instead of publishing as > >> informational RFC) that document so that it expired and vanished > >> from the I-D repository 6 month later. > > > > Seems like SSLv3 was simultaneously one of the most critical protocols > > for net security and orphaned. > > Stop right there. Don't be led down the garden path. > > Look at the parent page. Look at > http://web.archive.org/web/20050205162914/wp.netscape.com/eng/ssl3/ As I previously explained, I went to the Netscape WebServer in 2000 (when we acquired our OEM SSL implementation and I got the job to make it accessible to our application), and the Netscape site search sent me straight to the "pretty" SSLv3 spec (HTML and Postscript). When I found a reference to a SSLv3 spec from November a few weeks later, google did NOT find the 302 document. So I searched through the archives of the IETF TLS mailing list, where I finally found the document, because it had been posted there in full. The IETF internet-drafts repository in 1995-1998 kept only the most recent version of a draft (deleted all previous documents), and deleted an I-D when it expired. The possibility to access old internet draft versions through tools.ietf.org is something I learned a few weeks ago. Keeping an old version of a specification around in a MUCH MORE promentiently fashion for 9 years tells a lot about what Netscape thought of the draft-302.txt document. After all, Netscape originally would have loved the IETF to rubber stamp the original SSLv3 spec -- just that the IETF TLS WG didn't like the rubber stamping idea in 1995/1996 -- and instead insisted on defining a protocol named TLS backwards interoperable with SSLv3. So the draft302.txt document represents the start of TLSv1.0, and not the final spec of SSLv3. -Martin From nelson@bolyard.me Thu Dec 10 19:08: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 6EFDC3A67F2 for ; Thu, 10 Dec 2009 19:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il3KPdo4riqW for ; Thu, 10 Dec 2009 19:08:32 -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 A78043A682E for ; Thu, 10 Dec 2009 19:08:25 -0800 (PST) Received: (qmail 11373 invoked from network); 11 Dec 2009 03:08:13 -0000 Received: from unknown (24.5.142.42) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 11 Dec 2009 03:08:13 -0000 Message-ID: <4B21B79E.8060509@bolyard.me> Date: Thu, 10 Dec 2009 19:08: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: <200912110255.nBB2tE1V027686@fs4113.wdf.sap.corp> In-Reply-To: <200912110255.nBB2tE1V027686@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 03:08:33 -0000 On 2009-12-10 18:55 PST, Martin Rex wrote: > Nelson B Bolyard wrote: >>>>> That is interesting information. Would you happen to have a copy of the >>>>> last "official" spec you can send me? >>>> Netscape's official SSLv3 spec as of 2005: >>>> http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM >>> That's pretty clear, SSLv3 did not have a provision for extending Client >>> Hello. >>> >>>> As obvious from it's name that spec is a product of the TLS WG and >>>> the TLS WG decided to completely abandon (instead of publishing as >>>> informational RFC) that document so that it expired and vanished >>>> from the I-D repository 6 month later. >>> Seems like SSLv3 was simultaneously one of the most critical protocols >>> for net security and orphaned. >> Stop right there. Don't be led down the garden path. >> >> Look at the parent page. Look at >> http://web.archive.org/web/20050205162914/wp.netscape.com/eng/ssl3/ > Keeping an old version of a specification around in a MUCH > MORE promentiently fashion for 9 years tells a lot about what > Netscape thought of the draft-302.txt document. It's not "much more prominent". It's merely HTML. Prettier, perhaps. It amuses me that you tell me what Netscape did and didn't do with those pages, because *I* was the Netscape employee who maintained that section of the web site from 1998-2005, beginning when I implemented TLS 1.0 in Netscape's NSS. From djhopwood@googlemail.com Thu Dec 10 19:44:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8293A69CB for ; Thu, 10 Dec 2009 19:44: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 ieMUEVECN2FX for ; Thu, 10 Dec 2009 19:44:12 -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 BB5E63A69C5 for ; Thu, 10 Dec 2009 19:44:11 -0800 (PST) Received: by ewy6 with SMTP id 6so608348ewy.29 for ; Thu, 10 Dec 2009 19:43: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=5Bj4HC8yXc5J//Dac91sdE7K84nrpEDv8jRxHCyME1g=; b=aidLFGZ/wEB2g763R8fAPUNH0h80UaD6eLQ5tR3qKwllV54Wk82E0FBxb+yrrr3Kmv mHjdfIpVAFSFuNF9HKI8I2swPpK9W83N3txTFcIfERRFAxTSQfzwyLa2TAk+QTDaH046 z4FvsT/GovPKoAdDGV7/t53dQRbFihg6mkf9Y= 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=BuhaP2SUAt/krVlj9LDejeYgwB4gYL7XTM99BpyN/VWUx0aqccjovkGJvlm5ChunYW aCf292+Ma9EQAT8/mOTLwQwxrH3GDJRLI41pckP3j+4cr0gnRs0CMW94uMjjE11XM07V XUQJ6+czS4W2gSLlFQfF64Wg2sSAdOA6pmKGE= Received: by 10.213.46.148 with SMTP id j20mr936800ebf.1.1260503036596; Thu, 10 Dec 2009 19:43:56 -0800 (PST) Received: from ?192.168.0.2? (5e05ad48.bb.sky.com [94.5.173.72]) by mx.google.com with ESMTPS id 13sm898769ewy.1.2009.12.10.19.43.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 19:43:56 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B21BFF5.2020909@jacaranda.org> Date: Fri, 11 Dec 2009 03:43:49 +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: <200912110208.nBB28SIT024876@fs4113.wdf.sap.corp> In-Reply-To: <200912110208.nBB28SIT024876@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigB080F68ECC320FFF87156B1B" Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 03:44:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB080F68ECC320FFF87156B1B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Michael Gray wrote: >>> in order to reliably provide this, >>> >>> - MCSV is defined to represent an empty TLS extension RI >>> >>> - MSCV MUST be included in *ALL* initial ClientHello handshakes >>> messages _plus_ all renegotiation ClientHellos in backwards >>> interop scenarios (independent of full handshake or session resum= e). >>> >>> - empty TLS extension RI MUST NOT be sent, ever! >> >> This looks good to me, the only thing I would change is I think MUST N= OT >> would be better as SHOULD NOT as the later requires that the implement= er >> examine the conditions and implications etc to make the best decision.= >=20 > You are right. I'm sorry. I got a little carried away. >=20 > A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate. Why? What is the point of allowing the client to send an empty extension,= when a patched client MUST send the MSCV, and a patched server MUST use *only* the MSCV to determine whether the client is patched? You'd just be= adding the option to send an extension that has no defined meaning. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigB080F68ECC320FFF87156B1B 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/ iF4EAREIAAYFAkshv/0ACgkQWUc8YzyzqAc3owEAn/LQ1a3zLZfcnKyka2E8XJxl br17Ao+jkQT2rBmnZnsA/13EDS6CyNcCCDzs/NgLX8eU/tkdiTcj5FhEOh8L3qdi =gu/n -----END PGP SIGNATURE----- --------------enigB080F68ECC320FFF87156B1B-- From mickgray@au1.ibm.com Thu Dec 10 23:05: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 C24383A6A11 for ; Thu, 10 Dec 2009 23:05:39 -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 2TOggzIk6haU for ; Thu, 10 Dec 2009 23:05:39 -0800 (PST) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by core3.amsl.com (Postfix) with ESMTP id A00963A69B0 for ; Thu, 10 Dec 2009 23:05:37 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp03.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBB72aRw027658 for ; Fri, 11 Dec 2009 18:02:36 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBB71W4j1634554 for ; Fri, 11 Dec 2009 18:01:32 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBB75Mdr011608 for ; Fri, 11 Dec 2009 18:05:22 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBB75MbE011605; Fri, 11 Dec 2009 18:05:22 +1100 In-Reply-To: <4B21ACFD.8010701@bolyard.me> To: Nelson B Bolyard X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Fri, 11 Dec 2009 17:05:11 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 11/12/2009 18:12:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 07:05:40 -0000 tls-bounces@ietf.org wrote on 11/12/2009 12:22:53 PM: > On 2009-12-09 18:16 PST, Michael Gray wrote: > > > Given this large test impact I find the > > draft-mrex-tls-secure-renegotiation-03 alternate solution (which does not > > require full extension implementation) to be preferable. > > Of course, neither does draft-ietf-tls-renegotiation-01.txt require full > extension implementation, so the absence of that requirements is not a > basis for preference of one over the other. To be clear: draft-ietf-tls-renegotiation-01.txt requires data exchange by the RI extension whereas draft-mrex-tls-secure-renegotiation-03 does not. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Fri Dec 11 06:58: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 CC37328C0EE for ; Fri, 11 Dec 2009 06:58:43 -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 ewuQtutIdGWZ for ; Fri, 11 Dec 2009 06:58: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 8EA8D28C0E9 for ; Fri, 11 Dec 2009 06:58:42 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBBEwQSq010616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 15:58:26 +0100 (MET) From: Martin Rex Message-Id: <200912111458.nBBEwPFR008154@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 11 Dec 2009 15:58:25 +0100 (MET) In-Reply-To: <4B21B79E.8060509@bolyard.me> from "Nelson B Bolyard" at Dec 10, 9 07:08: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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 11 Dec 2009 14:58:43 -0000 Nelson B Bolyard wrote: > > > Keeping an old version of a specification around in a MUCH > > MORE promentiently fashion for 9 years tells a lot about what > > Netscape thought of the draft-302.txt document. > > It's not "much more prominent". It's merely HTML. Prettier, perhaps. Let's see: The following URL says "SPEC": http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM This URL says "Draft": http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft302.txt and includes an _explicit_ expiration of May 1997. And concerning extensibility of SSLv3, here's a statement from Tom Weinstein, listed in the Authors section of the Nov 18th, 1996 draft as a Netscape employee from 10-Oct-1996: http://www.imc.org/ietf-tls/mail-archive/msg00325.html The lack of a general extension mechanism in SSL v3 is a feature, not a bug. This is a security protocol, and so susceptibility to analysis is a good thing. Simplicity and rigidity are features here. SSL does provide for forwards compatibility by allowing version negotiation and protection from version rollback attacks. -Tom Weinstein, Netscape, 10-Oct-1996, Co-Author of draft302.txt So as far as Netscape's SSLv3 is concerned it didn't not contain extensibility. What is in that November draft is something the TLS WG wanted for TLSv1.0. Keep in mind that in mid of 1996, SSLv3 was not under development, it was already widely deployed. > > It amuses me that you tell me what Netscape did and didn't do with those > pages, because *I* was the Netscape employee who maintained that section > of the web site from 1998-2005, beginning when I implemented TLS 1.0 > in Netscape's NSS. You could have removed the explicit expiration notice on draft302.txt and you could have renamed it to "3.0 final SPEC", you could have removed the version that you condered outdated--or at least clearly marked it as outdated _in_the_document_ if that was what you or Netscape intended it to be. -Martin From mrex@sap.com Fri Dec 11 07: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 2038C3A6AE6 for ; Fri, 11 Dec 2009 07:11:19 -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 4btaEOuqoF18 for ; Fri, 11 Dec 2009 07:11:17 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4E2F43A6AE4 for ; Fri, 11 Dec 2009 07:11:17 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBBFB4cU023013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 16:11:04 +0100 (MET) From: Martin Rex Message-Id: <200912111511.nBBFB3Ej008905@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Fri, 11 Dec 2009 16:11:03 +0100 (MET) In-Reply-To: <4B21BFF5.2020909@jacaranda.org> from "David-Sarah Hopwood" at Dec 11, 9 03:43: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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 11 Dec 2009 15:11:19 -0000 David-Sarah Hopwood wrote: > > Martin Rex wrote: > > Michael Gray wrote: > >>> in order to reliably provide this, > >>> > >>> - MCSV is defined to represent an empty TLS extension RI > >>> > >>> - MSCV MUST be included in *ALL* initial ClientHello handshakes > >>> messages _plus_ all renegotiation ClientHellos in backwards > >>> interop scenarios (independent of full handshake or session resume). > >>> > >>> - empty TLS extension RI MUST NOT be sent, ever! > >> > >> This looks good to me, the only thing I would change is I think MUST NOT > >> would be better as SHOULD NOT as the later requires that the implementer > >> examine the conditions and implications etc to make the best decision. > > > > You are right. I'm sorry. I got a little carried away. > > > > A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate. > > Why? What is the point of allowing the client to send an empty extension, > when a patched client MUST send the MSCV, and a patched server MUST use > *only* the MSCV to determine whether the client is patched? You'd just be > adding the option to send an extension that has no defined meaning. I have mixed feelings about this. Maybe we do need a MUST to make things clear. There *IS* no point in doing that (which is why I lightheartedly wrote MUST NOT). An implementation that is sending it will just waste code and network bandwidth. As far as I understand there seem to be architectures where the ServerHello extensions parser will only search for replies to TLS extensions it requested (and ignore others). Now for the RENEGO_PROTECTION to reliably work against downgrade attacks in backwards interop scenarios, that code MUST be changed to process a TLS extension RI reply in ServerHello in cases where it did _NOT_ send an empty TLS extension RI in ClientHello--otherwise there would be no downgrade MitM attack protection. Therefore a mere SHOULD NOT might lead to defective/vulnerable implementations in case these implementations allow backwards interoperability or extension-less SSLv3 ClientHellos or SSLv2 ClientHellos. -Martin From marsh@extendedsubset.com Fri Dec 11 08: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 158103A6882 for ; Fri, 11 Dec 2009 08:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKm0JJGbI1Hu for ; Fri, 11 Dec 2009 08:33:43 -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 53FE33A6857 for ; Fri, 11 Dec 2009 08:33:43 -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 1NJ8Qt-000NfZ-8c; Fri, 11 Dec 2009 16:33:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0755A603A; Fri, 11 Dec 2009 16:33: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+gT5SgFGUoMZq94m3v7r37iSc0VG+6bz8= Message-ID: <4B227458.9080007@extendedsubset.com> Date: Fri, 11 Dec 2009 10:33:28 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood , "tls@ietf.org" References: <200912110208.nBB28SIT024876@fs4113.wdf.sap.corp> <4B21BFF5.2020909@jacaranda.org> In-Reply-To: <4B21BFF5.2020909@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] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 16:33:44 -0000 David-Sarah Hopwood wrote: > > Why? What is the point of allowing the client to send an empty extension, > when a patched client MUST send the MSCV, and a patched server MUST use > *only* the MSCV to determine whether the client is patched? You'd just be > adding the option to send an extension that has no defined meaning. I would like for the decisions we make today to allow the MCSV hack to be retired at some point in the future. MCSV represents extra complexity that we added as a concession for interoperability with obsolete and out-of-spec systems. We all have to make compromises in life and protocol design, but it is better to do it in such a way that they eventually pass into history rather than build up over time. Today there are many clients which never interoperate with extensions-intolerant servers. If at all possible, these should have the option of not sending the MCSV hack from the beginning. - Marsh From mrex@sap.com Fri Dec 11 08:58: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 9D6FB3A69FE for ; Fri, 11 Dec 2009 08:58:09 -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 ffEwVnGJkeAE for ; Fri, 11 Dec 2009 08:58: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 3F8FC3A67A4 for ; Fri, 11 Dec 2009 08:58:08 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBBGvrQe000396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 17:57:53 +0100 (MET) From: Martin Rex Message-Id: <200912111657.nBBGvqCC015029@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 11 Dec 2009 17:57:52 +0100 (MET) In-Reply-To: <4B227458.9080007@extendedsubset.com> from "Marsh Ray" at Dec 11, 9 10:33:28 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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 11 Dec 2009 16:58:09 -0000 Marsh Ray wrote: > > David-Sarah Hopwood wrote: > > > > Why? What is the point of allowing the client to send an empty extension, > > when a patched client MUST send the MSCV, and a patched server MUST use > > *only* the MSCV to determine whether the client is patched? You'd just be > > adding the option to send an extension that has no defined meaning. > > I would like for the decisions we make today to allow the MCSV hack to > be retired at some point in the future. MCSV represents extra complexity > that we added as a concession for interoperability with obsolete and > out-of-spec systems. We all have to make compromises in life and > protocol design, but it is better to do it in such a way that they > eventually pass into history rather than build up over time. > > Today there are many clients which never interoperate with > extensions-intolerant servers. If at all possible, these should have the > option of not sending the MCSV hack from the beginning. Today there are many car owners that are not involved in car accidents, we should get rid of liability insurances for cars. The problem with this reasoning is, that you only know _after_ the fact whether you needed it or not. You're actually suggesting that Browser vendors split their codebase in two (one with backwards interop and one without) for the gigantic gain of saving 10 LoC in one of the then two different lines of code? When browser vendors emphasize they know exactly when the last pre-trusted RootCA cert they're shipping is dropped from their distribution, then they boldly assume this is the time when no-one needs MD5-support anymore, completely ignoring the much higher numbers of non-commercial CAs that a lot of companies are using, self-signed certs, certs installed on devices and more. MD5 may be bad, but it is still better than nothing. Removing vital functionality in a knee-jerk reaction just because some implementer sees no more use for it in his personal environment might not be a very good idea. OK, if you're working for a software vendor and are looking for an extremely extended Xmas vacation, this might be an option to make it happen... -Martin From Pasi.Eronen@nokia.com Fri Dec 11 09:08: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 EEC103A69A0 for ; Fri, 11 Dec 2009 09:08:02 -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.478, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk3Xyb564JYv for ; Fri, 11 Dec 2009 09:08:02 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EA45D3A687B for ; Fri, 11 Dec 2009 09:08:01 -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 nBBH78hb002975; Fri, 11 Dec 2009 11:07:48 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 19:07:43 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Dec 2009 19:07:43 +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, 11 Dec 2009 19:07:38 +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, 11 Dec 2009 18:07:25 +0100 From: To: , Date: Fri, 11 Dec 2009 18:07:23 +0100 Thread-Topic: [TLS] Two drafts, two last calls ? Thread-Index: Acp52IsEuHxrJ/w3QsWb9R74SbBapgAqZ2kw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31E7EBED@NOK-EUMSG-01.mgdnok.nokia.com> References: <7802aa750912101220j72d873d0mda6220e2e9f406de@mail.gmail.com> In-Reply-To: <7802aa750912101220j72d873d0mda6220e2e9f406de@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Dec 2009 17:07:38.0723 (UTC) FILETIME=[7137BB30:01CA7A84] X-Nokia-AV: Clean Subject: Re: [TLS] Two drafts, two last calls ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 17:08:03 -0000 (wearing Area Director hat) Let me try to explain the IETF process here: This is not a competition between two drafts. The TLS WG has decided to work on a solution to this problem, and we already know that the document that will be standardized will have file name "draft-ietf-tls-renegotiation". However, it's clear from the IETF Last Call comments that it won't be version -01 as-is, but there will be at least version -02 (and perhaps more) with some changes. So the question at hand is what changes should be included in draft-ietf-tls-renegotiation-02 (or 03/04/...). A number of people have proposed various changes in the emails during the past couple of weeks. Martin has decided to write his proposed changes in the form of an Internet-Draft -- which is sometimes a better way to communicate such a proposal than just email (and this is not an uncommon way to communicate in IETF). Which changes get included in the final document depends on IETF community consensus, as judged by the IESG (and not, for example,=20 the editors/authors of the document). Although the IETF occasionally standardizes two different solutions to the same problem, this is not common. Also, during the IETF Last Call, I have not seen any indiciation from the community that they would like to see two very similar solutions standardized. Best regards, Pasi > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Yang Tse > Sent: 10 December, 2009 22:21 > To: tls@ietf.org > Subject: [TLS] Two drafts, two last calls ? >=20 > Hello, >=20 > Given the fact that draft-mrex-tls-secure-renegotiation has already > completed a two weeks period as an Internet-Draft, I would like to > know if the IETF Security Area Director will make a Last Call on this > draft, or if there are any reasons that prevents this from happening. >=20 > Cheers, > -- > -=3D[Yang]=3D- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From djhopwood@googlemail.com Fri Dec 11 10: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 3F6B63A68E9 for ; Fri, 11 Dec 2009 10:11: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 X+fQwQqlFd9C for ; Fri, 11 Dec 2009 10:11: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 EE7873A67FE for ; Fri, 11 Dec 2009 10:11:41 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so345763eyd.51 for ; Fri, 11 Dec 2009 10:11: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=7lLgJr9Hq+J69qmWvCXxoOU4S4hIIUHWaMJLeNK6+hU=; b=VOVQC4bLdFGpgVBTzmr69Brzt4h9oNH6bO1S8LAwN6m5KPpi1hPWe7H1pRhm6QTs53 1JEIn5EmKHXJpwseX1PQ7Ps40IRSQPzXYL34LHfpXLRD9sR8zsBR6jpkmsh2FipIk+Tn vgRzr391JDzqLV/EtpBsaw6MOJYA/J6lETjOU= 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=MNIIbdOv2P0uckpCRV9FcpzYTyBW03A9INTr0YgArIaFjGYFbc/jjENf4p5ExoXuqA 2Ei+FlsZTD29Rd7hkDW2Gca/7aMtYjn3PRiChEWziAJua8RV4jhshXmjPnhVHluc4T0V 8qPo0+9jPYqmmdpitLZY62DVRtpqCFigPpI7Y= Received: by 10.213.50.69 with SMTP id y5mr1865376ebf.48.1260555086111; Fri, 11 Dec 2009 10:11:26 -0800 (PST) Received: from ?192.168.0.2? (5e05ad48.bb.sky.com [94.5.173.72]) by mx.google.com with ESMTPS id 15sm1307353ewy.8.2009.12.11.10.11.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 10:11:25 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B228B4B.8020709@jacaranda.org> Date: Fri, 11 Dec 2009 18:11:23 +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: <200912111458.nBBEwPFR008154@fs4113.wdf.sap.corp> In-Reply-To: <200912111458.nBBEwPFR008154@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9D22D79B99EF6740E49FE849" Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 18:11:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9D22D79B99EF6740E49FE849 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Nelson B Bolyard wrote: >>> Keeping an old version of a specification around in a MUCH >>> MORE promentiently fashion for 9 years tells a lot about what >>> Netscape thought of the draft-302.txt document. >> It's not "much more prominent". It's merely HTML. Prettier, perhaps.= >=20 > Let's see: >=20 > The following URL says "SPEC": > http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SP= EC.HTM >=20 > This URL says "Draft": > http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draf= t302.txt >=20 > and includes an _explicit_ expiration of May 1997. This is really reaching. They are both *draft* *specifications*. Yes, the former should have been removed from the site, or marked as obsolete. That's water under the bridge now. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig9D22D79B99EF6740E49FE849 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/ iF4EAREIAAYFAksii1EACgkQWUc8YzyzqAfckAEAhNGQy0jwtPkbe3GbhCcasnEu sEADQfqIUzaypgn2cAMA/AoEcKKsOSRQAszDtfM9TZHPJtT05UKxCaJsSoldVrMv =duR5 -----END PGP SIGNATURE----- --------------enig9D22D79B99EF6740E49FE849-- From yangsita@gmail.com Fri Dec 11 10:15: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 D8F643A6A04 for ; Fri, 11 Dec 2009 10:15:10 -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.265, BAYES_00=-2.599, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8rfDSTj4o9s for ; Fri, 11 Dec 2009 10:15:10 -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 607783A6A01 for ; Fri, 11 Dec 2009 10:15:06 -0800 (PST) Received: by bwz23 with SMTP id 23so832451bwz.29 for ; Fri, 11 Dec 2009 10:14: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; bh=5rHpS4tK88Tqyn1mer8iHhr1dN0QfsazHpt0ECH1V30=; b=Y6iIw7OchC5bsHWsLdSYJ6WckLWBPQ2l3KSygXe7O63pF8YEwzF6hysLQPv4Uh+kyv wVjcDxEbLBymLkYOr1/bshwiIM2E5e3tQ5ZqjxsoRbNg+Ufbar7TO65pvKmTgbtA6ypT B6kT6dP1OHPNnWLKs7dnDIFwadXw0mDvnaqzw= 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=jMGXBFNjOWRrxmll8Kppv+dSQtOOst9/CrxyZw7/7ApnYKDDhkWU/NMLCGv1sQSfKx BhhJej0VaqumWweP7aHiEDtXVuukDQ4rXCZrkeMyPD2dMWz06gq19oTdYD6VJdxizCoL hlEACKOZZKgr9ZwfDzy8HvKmlcWW0NSK4pmW0= MIME-Version: 1.0 Received: by 10.204.3.78 with SMTP id 14mr974304bkm.129.1260555290578; Fri, 11 Dec 2009 10:14:50 -0800 (PST) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31E7EBED@NOK-EUMSG-01.mgdnok.nokia.com> References: <7802aa750912101220j72d873d0mda6220e2e9f406de@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31E7EBED@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 11 Dec 2009 19:14:50 +0100 Message-ID: <7802aa750912111014k2f32bf74p81301bce93597b80@mail.gmail.com> From: Yang Tse To: "Pasi.Eronen@nokia.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] Two drafts, two last calls ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 18:15:11 -0000 Pasi, Thanks for the IETF process explanation. Just wanted to be sure that draft-mrex-tls-secure-renegotiation contents would at some point be formally evaluated by IESG and would not simply become an I-D sitting on a shelve with no formal review. Cheers, -- -=[Yang]=- 2009/12/11, Pasi.Eronen@nokia.com : > (wearing Area Director hat) > > Let me try to explain the IETF process here: > > This is not a competition between two drafts. The TLS WG has decided > to work on a solution to this problem, and we already know that the > document that will be standardized will have file name > "draft-ietf-tls-renegotiation". > > However, it's clear from the IETF Last Call comments that it won't be > version -01 as-is, but there will be at least version -02 (and perhaps > more) with some changes. So the question at hand is what changes > should be included in draft-ietf-tls-renegotiation-02 (or 03/04/...). > > A number of people have proposed various changes in the emails during > the past couple of weeks. Martin has decided to write his proposed > changes in the form of an Internet-Draft -- which is sometimes a > better way to communicate such a proposal than just email (and this > is not an uncommon way to communicate in IETF). > > Which changes get included in the final document depends on IETF > community consensus, as judged by the IESG (and not, for example, > the editors/authors of the document). > > Although the IETF occasionally standardizes two different solutions to > the same problem, this is not common. Also, during the IETF Last Call, > I have not seen any indiciation from the community that they would > like to see two very similar solutions standardized. > > Best regards, > Pasi > > > -----Original Message----- > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > > ext Yang Tse > > Sent: 10 December, 2009 22:21 > > To: tls@ietf.org > > Subject: [TLS] Two drafts, two last calls ? > > > > Hello, > > > > Given the fact that draft-mrex-tls-secure-renegotiation has already > > completed a two weeks period as an Internet-Draft, I would like to > > know if the IETF Security Area Director will make a Last Call on this > > draft, or if there are any reasons that prevents this from happening. > > > > Cheers, > > -- > > -=[Yang]=- > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > From mike-list@pobox.com Fri Dec 11 11: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 EF8C43A6890 for ; Fri, 11 Dec 2009 11:34:43 -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 S95l0VZtjEWL for ; Fri, 11 Dec 2009 11:34: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 F35523A67A7 for ; Fri, 11 Dec 2009 11:34: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 3419087940 for ; Fri, 11 Dec 2009 14:34: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=KImrOWe/VBBV 47XUD1JcHB4DTVQ=; b=a/wtIFD2FOD0py41XAiL5p7NZo/eq1tXMxDMfrXe7eoX qBlj77GSZvi7w6VbNvdRT2YaCX+T2TrkFea/Af8pz8vInyrmWJwI7wWoBuT3Xm2a QlHEddLIbBFwVV+yY6ct41aj455y9zzWQ90IZv1J5rSxwnYizBOKOt2Eof6CyDM= 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=qaVb/b xWGVdeXMiG7xQ8wMLKdKX7ue1vc4A0B/45sSOp9wZEi3FOm/0LLRzFIzJRJh1hSg L59MTyH7LKrz1RCZVyP02EodfXfSnG1Emg8h0j+yvcfuQoRjkL52syUhIJqmP7mc Z5uD2SHl1fHqVR5vnOdRndR+1m2LFRp4Xv39g= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 28B1B8793E for ; Fri, 11 Dec 2009 14:34: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 8A60B8793D for ; Fri, 11 Dec 2009 14:34:29 -0500 (EST) Message-ID: <4B229F51.2040109@pobox.com> Date: Fri, 11 Dec 2009 11:36:49 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> In-Reply-To: <20091207220244.DA1A06C5242@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 3372BB1E-E68C-11DE-B350-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Closing some open comments on 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, 11 Dec 2009 19:34:44 -0000 Eric Rescorla wrote: > > 1. Replace "cipher suite" with magic cipher suite value (MCSV) > throughout. I'm not sure we want to call it "magic" in the RFC (even though I am probably guilty of calling it that in previous messages). Perhaps "special" would be a better adjective? Mike From stpeter@stpeter.im Fri Dec 11 11:38: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 3B5C43A6816 for ; Fri, 11 Dec 2009 11:38:44 -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 vmb+9zVjIIU3 for ; Fri, 11 Dec 2009 11:38:43 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 808093A67A7 for ; Fri, 11 Dec 2009 11:38:43 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D23354033C; Fri, 11 Dec 2009 12:38:30 -0700 (MST) Message-ID: <4B229FB5.3070603@stpeter.im> Date: Fri, 11 Dec 2009 12:38:29 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <4B229F51.2040109@pobox.com> In-Reply-To: <4B229F51.2040109@pobox.com> 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="------------ms090406030505040608070002" Cc: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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, 11 Dec 2009 19:38:44 -0000 This is a cryptographically signed message in MIME format. --------------ms090406030505040608070002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/11/09 12:36 PM, Michael D'Errico wrote: > Eric Rescorla wrote: >> >> 1. Replace "cipher suite" with magic cipher suite value (MCSV) >> throughout. > > I'm not sure we want to call it "magic" in the RFC (even though I > am probably guilty of calling it that in previous messages). > Perhaps "special" would be a better adjective? I think we'd rather be magic than "special" ;-) --------------ms090406030505040608070002 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 hvcNAQkFMQ8XDTA5MTIxMTE5MzgyOVowIwYJKoZIhvcNAQkEMRYEFPSuu3N9nEUcRJFFy9a7 DlnCpHKiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAU1wv3Ryhybr5Zb2lw2sW1pdDZXLu+6piHois3mDp 6BqyowMNEPzXK5hUGHudk4PGfmzeeFkoZBTMSNxwawfAEK+4/QWiEpOyExheTLi6A9OyX8AZ 89EtbkdUhVpmZuo5pIfXOVUHOiSOgwcnrtWpHAM8raMHCwXUZ7Bjz11dh7oPuAjORCrnKJ6w J+Fvoc/+8uqo9l/WY6SPuJSApvmCLpUV1h+FwnZ5cCLcE3KWHktliuFXb7iNxh/b/3YyEnJM ny0YrRa6qwfttDxPLz2jBpkkdzXF4epzRHnPWuDKSMZKh3n1qoVmeLWhfAHk2PmQhE52FlDp xk603dYjMlmIPwAAAAAAAA== --------------ms090406030505040608070002-- From mike-list@pobox.com Fri Dec 11 12:01: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 BD7DE3A69FC for ; Fri, 11 Dec 2009 12:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1Ki4BB4HNcH for ; Fri, 11 Dec 2009 12:01:04 -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 BFA6E3A69DA for ; Fri, 11 Dec 2009 12:01: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 AA1CA87BD1 for ; Fri, 11 Dec 2009 15:00: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=Vy9U44/r0Zhn wtmqUOg/9Thofrg=; b=Lpkhnx7sKoP+lEEOW2SHMcr3KfUwUOaVp7lQMUa8fnVr CwvXAcsDmFmPFNN01BwaHvL8U6noMT0c5Cgtyni+NvGL+RjIPJfBjfCCAzKHXuu/ NruI0zMtwRurflj75FMBvjlzcifTkRm0Ea1LnGEPMlH+uL4ruFKqcA0isJDw/68= 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=lEj+Sy dkhtD32jHDmYDZSSDtYta0T+anknYnbv4+fYCwJKQt1bKmoLPU5pt+xVheU+Q7xT 8tSYk/J4LS4CpsA/jZ0Vf1SM2dIE+O52G0s8cpis6BTGqydQKrIRU3Frmcthu3NF L9R78I59rrxahSNboXoO9XcHNwtom6yyu1Jfk= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9B30287BD0 for ; Fri, 11 Dec 2009 15:00: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 B181A87BCF for ; Fri, 11 Dec 2009 15:00:45 -0500 (EST) Message-ID: <4B22A575.4020803@pobox.com> Date: Fri, 11 Dec 2009 12:03:01 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <4B229F51.2040109@pobox.com> <4B229FB5.3070603@stpeter.im> In-Reply-To: <4B229FB5.3070603@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E0EAD634-E68F-11DE-9085-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Closing some open comments on 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, 11 Dec 2009 20:01:04 -0000 Peter Saint-Andre wrote: > On 12/11/09 12:36 PM, Michael D'Errico wrote: >> Eric Rescorla wrote: >>> 1. Replace "cipher suite" with magic cipher suite value (MCSV) >>> throughout. >> I'm not sure we want to call it "magic" in the RFC (even though I >> am probably guilty of calling it that in previous messages). >> Perhaps "special" would be a better adjective? > > I think we'd rather be magic than "special" ;-) Well, since the MCSV is an extension, but not a true extension, it is "special" even in the sense you suggest! ;-) Mike From cfinss@dial.pipex.com Fri Dec 11 12: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 9B8053A6890 for ; Fri, 11 Dec 2009 12:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-1.764, BAYES_20=-0.74, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_54=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 14--qZTA-FuE for ; Fri, 11 Dec 2009 12:04:57 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 55C763A6452 for ; Fri, 11 Dec 2009 12:04:57 -0800 (PST) X-Trace: 276988594/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.111/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.111 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAEM0Iks+vGRv/2dsb2JhbABCgjqFbIhnxE0KhCEEgWM X-IronPort-AV: E=Sophos;i="4.47,384,1257120000"; d="scan'208";a="276988594" X-IP-Direction: IN Received: from 1cust111.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.111]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Dec 2009 20:04:43 +0000 Message-ID: <002b01ca7a94$ebba8b20$0601a8c0@allison> From: "tom.petch" To: "Nelson B Bolyard" , References: <200912101613.nBAGD3X2016314@fs4113.wdf.sap.corp><4B216FD0.7060801@extendedsubset.com> <4B21B0E8.1080702@bolyard.me> Date: Fri, 11 Dec 2009 11:27:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 20:04:58 -0000 ----- Original Message ----- From: "Nelson B Bolyard" Sent: Friday, December 11, 2009 3:39 AM > On 2009-12-10 14:01 PST, Marsh Ray wrote: > > Martin Rex wrote: > > Seems like SSLv3 was simultaneously one of the most critical protocols > > for net security and orphaned. > > Stop right there. Don't be led down the garden path. > > Look at the parent page. Look at > http://web.archive.org/web/20050205162914/wp.netscape.com/eng/ssl3/ > > It clearly says that "The most recent Draft SSL 3.0 specification, an > Internet Draft dated November 1996, may be viewed here. It is an ASCII > document". It is a link to http://wp.netscape.com/eng/ssl3/draft302.txt > which is draft-freier-ssl-version3-02.txt, now seen at > http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt Weirder and weirder. Yes, you are right (of course) and I now have a copy of -02. But.... When I go to tools.ietf and ask for draft-freier, it produces -01; if I ask explicitly for -02, it produces -01. Go to Watersprings (which I always do before using tools.ietf) and it tells me of -00 and -01 and that the last was superseded by draft-tls-... So both the ietf archive and the Watersprings archive deny knowledge of -02, which, in any other circumstance, I would take as proof beyond reasonable doubt that there never was a -02. Ah well, they never said the security was easy. Tom Petch > That parent page also says: "The previous draft of the SSL 3.0 > Specification, dated March 1996, may be viewed in this HTML document." > which is a link to > http://web.archive.org/web/20050206124632/wp.netscape.com/eng/ssl3/ssl-toc.html > which in turn has a link to the page Martin cited above. > > You'll find my name in some of those pages, too. Don't let a non-Netscape > person tell you what was, and what was not "official" at Netscape. > > Netscape never orphaned 3.0. It kept the "most recent draft" alive for > the rest of its days, and is still kept alive today at Mozilla.org, which > runs NSS code which is a direct descendant of Netscape's original code. From paul.hoffman@vpnc.org Fri Dec 11 12:11: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 144F13A6876 for ; Fri, 11 Dec 2009 12:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.083, 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 9pWZmZmDs6B6 for ; Fri, 11 Dec 2009 12:11:17 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 322DE3A672F for ; Fri, 11 Dec 2009 12:11:16 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBBKAwAA079283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 13:11:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7802aa750912111014k2f32bf74p81301bce93597b80@mail.gmail.com> References: <7802aa750912101220j72d873d0mda6220e2e9f406de@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31E7EBED@NOK-EUMSG-01.mgdnok.nokia.com> <7802aa750912111014k2f32bf74p81301bce93597b80@mail.gmail.com> Date: Fri, 11 Dec 2009 12:10:57 -0800 To: Yang Tse , "Pasi.Eronen@nokia.com" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: tls@ietf.org Subject: Re: [TLS] Two drafts, two last calls ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 20:11:18 -0000 At 7:14 PM +0100 12/11/09, Yang Tse wrote: >Just wanted to be sure that draft-mrex-tls-secure-renegotiation >contents would at some point be formally evaluated by IESG and would >not simply become an I-D sitting on a shelve with no formal review. That's not what he said. He said: >2009/12/11, Pasi.Eronen@nokia.com : > > This is not a competition between two drafts. The TLS WG has decided > > to work on a solution to this problem, and we already know that the > > document that will be standardized will have file name > > "draft-ietf-tls-renegotiation". > >. . . > >> Which changes get included in the final document depends on IETF >> community consensus, as judged by the IESG (and not, for example, > > the editors/authors of the document). If the IETF community consensus is to not include the features of draft-mrex-tls-secure-renegotiation into draft-ietf-tls-renegotiation, then those features will probably not be evaluated by the IESG. --Paul Hoffman, Director --VPN Consortium From mrex@sap.com Fri Dec 11 12:25: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 9BA6E3A68A6 for ; Fri, 11 Dec 2009 12:25:17 -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 lrEYuOGpHjW1 for ; Fri, 11 Dec 2009 12:25:16 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3DB263A6890 for ; Fri, 11 Dec 2009 12:25:16 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBBKP2qA001907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 21:25:02 +0100 (MET) From: Martin Rex Message-Id: <200912112025.nBBKP1aQ027145@fs4113.wdf.sap.corp> To: yangsita@gmail.com (Yang Tse) Date: Fri, 11 Dec 2009 21:25:01 +0100 (MET) In-Reply-To: <7802aa750912111014k2f32bf74p81301bce93597b80@mail.gmail.com> from "Yang Tse" at Dec 11, 9 07:14:50 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] Two drafts, two last calls ? 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, 11 Dec 2009 20:25:17 -0000 Yang Tse wrote: > > Just wanted to be sure that draft-mrex-tls-secure-renegotiation > contents would at some point be formally evaluated by IESG and would > not simply become an I-D sitting on a shelve with no formal review. The submission of a document/proposal as an internet-draft itself is _not_ a request for review by the IESG. Chris Newman asked me to write up and submit my proposal as a draft, and Joe Salowey asked the WG in a consensus call for a specific proposal that people would support, so I wrote that document. What I do _not_ want is two solutions for this problem, that would be incompatible with my objectives. There were several motivations for me to do this: (1) the KISS principle http://en.wikipedia.org/wiki/KISS_principle (2) usable for all protocol versions of TLS plus SSLv3 (3) can easily and safely be used for backwards interoperability scenarios (4) enable non-disruptive updates of the installed base (1) if you look at http://en.wikipedia.org/wiki/KISS_principle you find the following: The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. This compares well to the maintenance people that will be tasked to retrofit secure renegotiation (or the RI-Minimal renegotiation-less version thereof) into old lines of code that they know marginally at best, plus the targets: fast patch development, quick and broad deployment into an installed base of largely unknown usage scenarios. Most of the maintenance guys do NOT have TLS extensions code, so in spite of their availability to engineers of new products, TLS extensions is something that is definitely not available in the toolchest of the average mechanic out in the field! (2) I found it completely unacceptable that the original proposal completely ignored the protocol version { 0x03, 0x00 } in spite of knowing that a _even_ a non-negligible amount of the HTTP traffic on the internet uses this protocol version--in intranets the usage of protocol { 0x03 0x00 } is probably even higher. (3) Since there will be a non-zero transition period where interop with old TLS peers is an absolute requirement for many implementations, a reliable protection from downgrade attacks is necessary. (4) Since the is are still old SSL and TLS implementations in current use with limited forward interoperability, hotfixing a feature into the installed base that has a proven track record of allergic reaction is a bad idea. Compare it to swine flu vaccine. If you had the choice between two vaccines, one with a 1% risk of anaphylactic shock and one with only 0,01% risk which one would you want to get treated with? And if you were a medical doctor in the US and had both of these available, which one would you give your high-profile customers? From frantz@pwpconsult.com Fri Dec 11 13:14: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 CFEC93A688D for ; Fri, 11 Dec 2009 13:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=-0.299, 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 F6X7XBxXCaPT for ; Fri, 11 Dec 2009 13:14:54 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id E63C63A657C for ; Fri, 11 Dec 2009 13:14:53 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NJCoz-00026a-E1; Fri, 11 Dec 2009 16:14:41 -0500 Date: Fri, 11 Dec 2009 13:15:35 -0800 From: Bill Frantz To: Michael D'Errico X-Priority: 3 In-Reply-To: <4B229F51.2040109@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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796a3f7d6ed32dc2318bd8fcfb8ccda8e1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Cc: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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, 11 Dec 2009 21:14:54 -0000 mike-list@pobox.com (Michael D'Errico) on Friday, December 11, 2009 wrote: >Eric Rescorla wrote: >>=20 >> 1. Replace "cipher suite" with magic cipher suite value (MCSV)=20 >> throughout. > >I'm not sure we want to call it "magic" in the RFC (even though I >am probably guilty of calling it that in previous messages). >Perhaps "special" would be a better adjective? Or perhaps, in a moment of candor, kludge cipher suite value (KCSV). Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 From lists@drh-consultancy.demon.co.uk Fri Dec 11 13:21: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 7E7193A681A for ; Fri, 11 Dec 2009 13:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 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 uFiHgiaXywoM for ; Fri, 11 Dec 2009 13:21:47 -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 0622A3A657C for ; Fri, 11 Dec 2009 13:21:46 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49948 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 1NJCvc-00063Y-CR for tls@ietf.org (return-path ); Fri, 11 Dec 2009 21:21:33 +0000 Message-ID: <4B22B7E3.30903@drh-consultancy.demon.co.uk> Date: Fri, 11 Dec 2009 21:21:39 +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] Closing some open comments on 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, 11 Dec 2009 21:21:53 -0000 Bill Frantz wrote: > mike-list@pobox.com (Michael D'Errico) on Friday, December 11, 2009 wrote: > >> Eric Rescorla wrote: >>> 1. Replace "cipher suite" with magic cipher suite value (MCSV) >>> throughout. >> I'm not sure we want to call it "magic" in the RFC (even though I >> am probably guilty of calling it that in previous messages). >> Perhaps "special" would be a better adjective? > > Or perhaps, in a moment of candor, kludge cipher suite value (KCSV). > The test version of OpenSSL has it set to 0FEC which was roughly speaking my reaction when I heard of the vulnerability in the first place. 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 wtc@google.com Fri Dec 11 14:09: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 A799D3A6880 for ; Fri, 11 Dec 2009 14:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.893 X-Spam-Level: X-Spam-Status: No, score=-101.893 tagged_above=-999 required=5 tests=[AWL=-4.084, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_FORGED_GMAIL=0.622, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100, WEIRD_PORT=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 rwYFvW5CDXTz for ; Fri, 11 Dec 2009 14:09:30 -0800 (PST) Received: from smtp-out.google.com (216-239-44-51.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 19AA73A6874 for ; Fri, 11 Dec 2009 14:09:29 -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 nBBM9H1j030708 for ; Fri, 11 Dec 2009 14:09:17 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260569357; bh=5OzgOmNa+7TFeFCY3Mjqa21A3t8=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=p9PicFMV6Ky5Aa8pEnz6ZnGwc6rj7jB8GNzPOEp92Q2A6vOdK6RKobUeg6DMd4ny2 Rlvnyaejk/aof5UBSBTPg== 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=PwLPQY5dyj01NId5lTA7IB4lkncfPW+zC4B8rhJJ0a9LhD2vCcLmEZ7B0mas9/Aby nN4fBH2HT9ujpf1CPPrqQ== Received: from pwj2 (pwj2.prod.google.com [10.241.219.66]) by spaceape11.eur.corp.google.com with ESMTP id nBBM8vcg025147 for ; Fri, 11 Dec 2009 14:09:14 -0800 Received: by pwj2 with SMTP id 2so847212pwj.34 for ; Fri, 11 Dec 2009 14:09:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.249.24 with SMTP id w24mr1113692wah.146.1260569353962; Fri, 11 Dec 2009 14:09:13 -0800 (PST) Date: Fri, 11 Dec 2009 14:09:13 -0800 Message-ID: From: Wan-Teh Chang To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [TLS] Concrete examples of TLS-intolerant servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 22:09:31 -0000 The following information was accurate as of yesterday, 2009-12-10. All information is public, coming from Google Chrome bug reports. I identify the servers by their behavior and by the Server headers in the HTTP responses. I tested the servers using Mac OS X 10.5 (TLS 1.0 without extensions) and Windows Vista (TLS 1.0 with extensions) and inspected the handshake messages. I didn't test TLS 1.1 or 1.2. 1. https://militarybankonline.bankofamerica.com/efs/servlet/military/login.jsp "Server: IBM_HTTP_Server/6.0.2.15 Apache/2.0.47 (Unix) DAV/2" Intolerant of TLS extensions. Respond by closing the TCP connection without sending TLS alerts. Update: Today (2009-12-11) this server properly ignores TLS extensions and identifies itself as "Server: IBM_HTTP_Server/6.0.2.33 Apache/2.0.47 (Unix) DAV/2" 2. https://www.cdep.ro/ Server unknown because SSL client auth is required. Intolerant of TLS extensions. Respond with an illegal_parameter alert. 3. https://welcome27.co-operativebank.co.uk/CBIBSWeb/start.do "Server: IBM_HTTP_Server" Intolerant of TLS extensions. Respond by closing the TCP connection without sending TLS alerts. 4. https://stud.infostud.uniroma1.it:4445/Sest/Log/Corpo.html "Server: OracleAS-Web-Cache-10g/10.1.2.0.2" Intolerant of TLS. Respond with an (SSL 3.0) unexpected_message alert. 5. https://www.bankalbilad.com.sa/retail/logon.do "Server: Bab web server" Intolerant of TLS. Respond with an (SSL 3.0) handshake_failure alert. 6. Oracle Application Server "Server: Oracle-Application-Server-10g/10.1.2.0.2 Oracle-HTTP-Server" Intolerant of TLS extensions. Respond with an illegal_parameter alert. 7. https://www.sbbt.com/personal-home.php "Server: IBM_HTTP_Server" Intolerant of TLS extensions. Respond by closing the TCP connection without sending TLS alerts. Wan-Teh Chang From nelson@bolyard.me Fri Dec 11 14:41: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 456D93A67F6 for ; Fri, 11 Dec 2009 14:41:33 -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 d1xoC56sieGB for ; Fri, 11 Dec 2009 14:41:32 -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 092AD3A67FB for ; Fri, 11 Dec 2009 14:41:31 -0800 (PST) Received: (qmail 2724 invoked from network); 11 Dec 2009 22:41:19 -0000 Received: from unknown (24.5.142.42) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 11 Dec 2009 22:41:19 -0000 Message-ID: <4B22CA88.7030007@bolyard.me> Date: Fri, 11 Dec 2009 14:41: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: <200912111458.nBBEwPFR008154@fs4113.wdf.sap.corp> In-Reply-To: <200912111458.nBBEwPFR008154@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 22:41:33 -0000 On 2009-12-11 06:58 PST, Martin Rex wrote: > Nelson B Bolyard wrote: >>> Keeping an old version of a specification around in a MUCH >>> MORE promentiently fashion for 9 years tells a lot about what >>> Netscape thought of the draft-302.txt document. >> It's not "much more prominent". It's merely HTML. Prettier, perhaps. > > > Let's see: > > The following URL says "SPEC": > http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM > > This URL says "Draft": > http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft302.txt > > and includes an _explicit_ expiration of May 1997. Yes, all the drafts expired, including the one that says "spec". > And concerning extensibility of SSLv3, here's a statement > from Tom Weinstein, listed in the Authors section of the > Nov 18th, 1996 draft as a Netscape employee from > 10-Oct-1996: > > http://www.imc.org/ietf-tls/mail-archive/msg00325.html > > The lack of a general extension mechanism in SSL v3 is a feature, not a > bug. This is a security protocol, and so susceptibility to analysis is > a good thing. Simplicity and rigidity are features here. SSL does > provide for forwards compatibility by allowing version negotiation and > protection from version rollback attacks. > > -Tom Weinstein, Netscape, 10-Oct-1996, Co-Author of draft302.txt Tom and I shared a cubicle. His brother Jeff sat in the next cubicle over. One of my first mistakes in working on NSS's SSL code was changing the code for handling received client hellos to require that the length of the message be exact, with no extra. Tom caught this mistake in his review of my patch. That was one of my first lessons learned in working on SSL in 1997. > So as far as Netscape's SSLv3 is concerned it didn't not contain > extensibility. In your opinion. If you wish, you may continue to try to get the last word in on this subject, but I think the group decision will not be based on who gets the last word. >> It amuses me that you tell me what Netscape did and didn't do with those >> pages, because *I* was the Netscape employee who maintained that section >> of the web site from 1998-2005, beginning when I implemented TLS 1.0 >> in Netscape's NSS. > > You could have removed the explicit expiration notice on draft302.txt > and you could have renamed it to "3.0 final SPEC", you could have > removed the version that you condered outdated--or at least clearly > marked it as outdated _in_the_document_ if that was what you or > Netscape intended it to be. I consciously chose to make NO changes at all to any of those documents, lest anyone accuse Netscape of continuing to try to revise the SSL 3.0 specification rather than (or in parallel with) adopting the TLS 1.0 specification. From mrex@sap.com Fri Dec 11 15:08: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 5F9FE3A68F6 for ; Fri, 11 Dec 2009 15:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 39mciLoEnSHT for ; Fri, 11 Dec 2009 15:07: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 D954F3A67F6 for ; Fri, 11 Dec 2009 15:07:58 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBBN7fRL019969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Dec 2009 00:07:41 +0100 (MET) From: Martin Rex Message-Id: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Sat, 12 Dec 2009 00:07:40 +0100 (MET) In-Reply-To: <4B22CA88.7030007@bolyard.me> from "Nelson B Bolyard" at Dec 11, 9 02:41:12 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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 11 Dec 2009 23:08:00 -0000 Nelson B Bolyard wrote: > > > The following URL says "SPEC": > > http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM > > This URL says "Draft": > > http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft302.txt > > > > and includes an _explicit_ expiration of May 1997. > > Yes, all the drafts expired, including the one that says "spec". Nope. The one calles SPEC does NOT have an expiration. When I complained to the supplier of our OEM SSL implementation about an interop problem with TLS (not extension, only { 0x03, 0x01 }) in August 2000, then they told me that the behaviour was according to the SSLv3 spec. I asked them for their spec document, and it was the March document. So I went to www.netscape.com and used their "Site Search", and the only document it found was the pretty (short) version of the SSLv3 spec. Then I saw the reference to a Nov 18th document in the TLSv1.0 spec (but not the slightest hint where to find it), and thats when I downloaded the ietf-tls discussion list archive and found the document attached to a posting from Win Treese (that attachment seems to have been stripped in the current archive, it was attached to this message. http://www.imc.org/ietf-tls/mail-archive/msg00422.html And although Win wrote this: "For a variety of reasons, it's important to have this draft for the record." neither TLS WG nor Netscape did anything substantial to keep this document on record. When I found that draft, I sent it to our supplier, so they would use it. But I could not blame them for not being aware of a newer document, because it was obviously a big mess and no one cared. > > > http://www.imc.org/ietf-tls/mail-archive/msg00325.html > > > > The lack of a general extension mechanism in SSL v3 is a feature, not a > > bug. This is a security protocol, and so susceptibility to analysis is > > a good thing. Simplicity and rigidity are features here. SSL does > > provide for forwards compatibility by allowing version negotiation and > > protection from version rollback attacks. > > > > -Tom Weinstein, Netscape, 10-Oct-1996, Co-Author of draft302.txt > > Tom and I shared a cubicle. His brother Jeff sat in the next cubicle over. > One of my first mistakes in working on NSS's SSL code was changing the code > for handling received client hellos to require that the length of the > message be exact, with no extra. Tom caught this mistake in his review of > my patch. I do believe that. If you look at the TLS mailing list archives, Tom was flamed violently for making such a statement. He sure hadn't forgotten that. But as you can see in the referenced message above, Barb Fox (Microsft) clearly points out that _NONE_ of the installed base of SSLv3 in Oct-1996 was extensible and neither was there an SSLv3 spec available providing this extensibility. > > > You could have removed the explicit expiration notice on draft302.txt > > and you could have renamed it to "3.0 final SPEC", you could have > > removed the version that you condered outdated--or at least clearly > > marked it as outdated _in_the_document_ if that was what you or > > Netscape intended it to be. > > I consciously chose to make NO changes at all to any of those documents, > lest anyone accuse Netscape of continuing to try to revise the SSL 3.0 > specification rather than (or in parallel with) adopting the TLS 1.0 > specification. Regrettably you did _NOT_ remove the expiration tag from the draft302 and did _NOT_ take down the outdated draft either. You should have put up the "Beware of the Leopard" sign on your overview page to make the picture complete. -Martin From nelson@bolyard.me Fri Dec 11 15:18: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 D57C33A68FB for ; Fri, 11 Dec 2009 15:18:23 -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 IPAp+OQW8xDv for ; Fri, 11 Dec 2009 15:18:23 -0800 (PST) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id EECF23A68C7 for ; Fri, 11 Dec 2009 15:18:22 -0800 (PST) Received: (qmail 29382 invoked from network); 11 Dec 2009 23:18:10 -0000 Received: from unknown (24.5.142.42) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 11 Dec 2009 23:18:10 -0000 Message-ID: <4B22D333.1000202@bolyard.me> Date: Fri, 11 Dec 2009 15:18: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: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp> In-Reply-To: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2009 23:18:24 -0000 On 2009-12-11 15:07 PST, Martin Rex wrote: > When I complained to the supplier of our OEM SSL implementation about > an interop problem with TLS (not extension, only { 0x03, 0x01 }) in > August 2000, then they told me that the behaviour was according to > the SSLv3 spec. They were mistaken about that, of course. There never was ANY doubt or controversy about how version negotiation was supposed to work. Some vendors just got it wrong. >>> You could have removed the explicit expiration notice on draft302.txt >>> and you could have renamed it to "3.0 final SPEC", you could have >>> removed the version that you condered outdated--or at least clearly >>> marked it as outdated _in_the_document_ if that was what you or >>> Netscape intended it to be. >> >> I consciously chose to make NO changes at all to any of those documents, >> lest anyone accuse Netscape of continuing to try to revise the SSL 3.0 >> specification rather than (or in parallel with) adopting the TLS 1.0 >> specification. > > Regrettably you did _NOT_ remove the expiration tag from the draft302 > and did _NOT_ take down the outdated draft either. > > You should have put up the "Beware of the Leopard" sign on your > overview page to make the picture complete. Just call me "Pounce". :) From djhopwood@googlemail.com Fri Dec 11 16:22: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 22F103A68B4 for ; Fri, 11 Dec 2009 16:22: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 Kx2anAoy8WZP for ; Fri, 11 Dec 2009 16:22:53 -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 B30073A6905 for ; Fri, 11 Dec 2009 16:22:52 -0800 (PST) Received: by ewy1 with SMTP id 1so1767775ewy.28 for ; Fri, 11 Dec 2009 16:22: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=9PTdikifGkFDB2PjfqLaemcHC5EJM05mWEMvloygkYY=; b=VVVSO5XNWUIp+NKBq7O+2MWDJyfgJpK8ZQj1M4ZdnOnzkixMLGFF0uaIqRsDVdbOdF 8vUHn1K5zTp3mNoxhbEGH3ER966UO/Kx7cTJjTvuxvdFbxtBDgxgaacxgDWJcBh/uYVf MNKs6WeCo8BR/VX027FlxfLPaeI6lH3dz211Y= 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=KhX0QC+jc/nPGHmS4KnlEGcyOb8crGu41Bk4mh3PLIFrGSuyOhQ0oxsvzRhtsZp7WA 0dJFlscn5/QQ1dO4sWyNIhz3dv35WNfF/i6bm6HbWrBOTH5LD7FcEJTBA4goUkjdqwxD mx9+7ALfY9YrDRml/JwBerUE27GHyPEFymwG8= Received: by 10.213.63.14 with SMTP id z14mr177828ebh.17.1260577357688; Fri, 11 Dec 2009 16:22:37 -0800 (PST) Received: from ?192.168.0.2? (5e05ad48.bb.sky.com [94.5.173.72]) by mx.google.com with ESMTPS id 13sm1516012ewy.1.2009.12.11.16.22.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 16:22:36 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B22E23B.4090005@jacaranda.org> Date: Sat, 12 Dec 2009 00:22: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: <20091207220244.DA1A06C5242@kilo.networkresonance.com> <4B229F51.2040109@pobox.com> In-Reply-To: <4B229F51.2040109@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig658829D90307DF5CC617ECC0" Subject: Re: [TLS] Closing some open comments on 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, 12 Dec 2009 00:22:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig658829D90307DF5CC617ECC0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > Eric Rescorla wrote: >> >> 1. Replace "cipher suite" with magic cipher suite value (MCSV) =20 >> throughout. >=20 > I'm not sure we want to call it "magic" in the RFC (even though I > am probably guilty of calling it that in previous messages). > Perhaps "special" would be a better adjective? Signalling cipher suite value? --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig658829D90307DF5CC617ECC0 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/ iF4EAREIAAYFAksi4koACgkQWUc8YzyzqAdK8gD9Fo/PulOy0z5R05+WMw8BRjWM hf5phWpfEsYE8qT6kEsA/1fh4hMiwZEBiO9wDniEiWqm+fx7vDAWt3VC2LVmGDHZ =Chds -----END PGP SIGNATURE----- --------------enig658829D90307DF5CC617ECC0-- From s@pahtak.org Fri Dec 11 19:34: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 85CF63A67F2 for ; Fri, 11 Dec 2009 19:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcgNaNsrLuMI for ; Fri, 11 Dec 2009 19:34:55 -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 A65B33A68B1 for ; Fri, 11 Dec 2009 19:34:55 -0800 (PST) Received: by gxk28 with SMTP id 28so1638601gxk.9 for ; Fri, 11 Dec 2009 19:34:40 -0800 (PST) Received: by 10.90.215.9 with SMTP id n9mr2419023agg.98.1260588880665; Fri, 11 Dec 2009 19:34:40 -0800 (PST) Received: from mb.pahtak.org (ip68-107-82-55.sd.sd.cox.net [68.107.82.55]) by mx.google.com with ESMTPS id 9sm938425ywf.50.2009.12.11.19.34.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 19:34:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Checkoway In-Reply-To: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp> Date: Fri, 11 Dec 2009 19:34:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp> To: tls@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2009 03:34:56 -0000 On Dec 11, 2009, at 3:07 PM, Martin Rex wrote: > Nelson B Bolyard wrote: >>=20 >>> The following URL says "SPEC": >>> = http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.= HTM >>> This URL says "Draft": >>> = http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft30= 2.txt >>>=20 >>> and includes an _explicit_ expiration of May 1997. >>=20 >> Yes, all the drafts expired, including the one that says "spec". >=20 > Nope. The one calles SPEC does NOT have an expiration. Not that this matters at all for the purposes of fixing TLS, but in what = way does it not have an expiration? The first paragraph establishes that = the document is an Internet-Draft. The second paragraph reminds readers = that Internet-Drafts expire after six months. = = makes clear that this document is more than six months old. That draft = has expired. --=20 Steve Checkoway From yngve@opera.com Sat Dec 12 10:33: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 9ABB33A6953 for ; Sat, 12 Dec 2009 10:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.181 X-Spam-Level: X-Spam-Status: No, score=-5.181 tagged_above=-999 required=5 tests=[AWL=-1.182, 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 UdWxOKcvJM7Z for ; Sat, 12 Dec 2009 10:33:14 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 5AC853A6848 for ; Sat, 12 Dec 2009 10:33:14 -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 nBCIUsf7004493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 12 Dec 2009 18:31:00 GMT Date: Sat, 12 Dec 2009 19:32:59 +0100 To: "Paul Hoffman" , 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] Please be specific: RI alone, RI with MCSV, or MCSV alone 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: Sat, 12 Dec 2009 18:33:15 -0000 On Thu, 10 Dec 2009 19:23:50 +0100, Paul Hoffman wrote: > While following the numerous threads, it seems that some people are > advocating adding MCSV to RI, while others are advocating RI by itself > (no MCSV), while others are advocating MCSV by itself (instead of RI). > > Can people please be more specific which proposal they are advocating? > It greatly affects the conversation. Thanks! I support the RI, with MCSV added since it appears to be necessary in some situations. I do not support MCSV without RI. -- 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 Sat Dec 12 11:34: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 856E03A68AF for ; Sat, 12 Dec 2009 11:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.679 X-Spam-Level: X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_40=-0.185, WEIRD_PORT=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 dWYMzw65lzwq for ; Sat, 12 Dec 2009 11:34:18 -0800 (PST) Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by core3.amsl.com (Postfix) with ESMTP id 76FED3A68A7 for ; Sat, 12 Dec 2009 11:34:18 -0800 (PST) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 8708448E7; Sat, 12 Dec 2009 19:34:04 +0000 (GMT) Received: from [10.87.48.10] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id nBCJY0uf021000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 12 Dec 2009 19:34:00 GMT Message-ID: <4B23F022.4090303@cs.tcd.ie> Date: Sat, 12 Dec 2009 19:33:54 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Wan-Teh Chang 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.9999 (Score 5) X-Canit-Stats-ID: 59214548 - 427253632f0a X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Cc: tls@ietf.org Subject: Re: [TLS] Concrete examples of TLS-intolerant servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2009 19:34:19 -0000 So that's 7-1 (fixed) = 6 extension intolerant servers out of how many? Hard to decide what this means otherwise. S. Wan-Teh Chang wrote: > The following information was accurate as of yesterday, 2009-12-10. > All information is public, coming from Google Chrome bug reports. > > I identify the servers by their behavior and by the Server headers > in the HTTP responses. > > I tested the servers using Mac OS X 10.5 (TLS 1.0 without extensions) > and Windows Vista (TLS 1.0 with extensions) and inspected the > handshake messages. I didn't test TLS 1.1 or 1.2. > > 1. https://militarybankonline.bankofamerica.com/efs/servlet/military/login.jsp > "Server: IBM_HTTP_Server/6.0.2.15 Apache/2.0.47 (Unix) DAV/2" > Intolerant of TLS extensions. Respond by closing the TCP connection > without sending TLS alerts. > > Update: Today (2009-12-11) this server properly ignores TLS extensions > and identifies itself as > "Server: IBM_HTTP_Server/6.0.2.33 Apache/2.0.47 (Unix) DAV/2" > > 2. https://www.cdep.ro/ > Server unknown because SSL client auth is required. > Intolerant of TLS extensions. Respond with an illegal_parameter alert. > > 3. https://welcome27.co-operativebank.co.uk/CBIBSWeb/start.do > "Server: IBM_HTTP_Server" > Intolerant of TLS extensions. Respond by closing the TCP connection > without sending TLS alerts. > > 4. https://stud.infostud.uniroma1.it:4445/Sest/Log/Corpo.html > "Server: OracleAS-Web-Cache-10g/10.1.2.0.2" > Intolerant of TLS. Respond with an (SSL 3.0) unexpected_message alert. > > 5. https://www.bankalbilad.com.sa/retail/logon.do > "Server: Bab web server" > Intolerant of TLS. Respond with an (SSL 3.0) handshake_failure alert. > > 6. Oracle Application Server > "Server: Oracle-Application-Server-10g/10.1.2.0.2 Oracle-HTTP-Server" > Intolerant of TLS extensions. Respond with an illegal_parameter alert. > > 7. https://www.sbbt.com/personal-home.php > "Server: IBM_HTTP_Server" > Intolerant of TLS extensions. Respond by closing the TCP connection > without sending TLS alerts. > > Wan-Teh Chang > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From yngve@opera.com Sat Dec 12 12:01: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 603B13A68A4 for ; Sat, 12 Dec 2009 12:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 AN-FoPOJe5dc for ; Sat, 12 Dec 2009 12:01:35 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id D52A13A68D1 for ; Sat, 12 Dec 2009 12:01:33 -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 nBCJxIZ5006884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 12 Dec 2009 19:59:20 GMT Date: Sat, 12 Dec 2009 21:01: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] RI, TLS Extension tolerance and version tolerance in servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2009 20:01:36 -0000 Hello all, With the introduction of the RI extension it seems to me that the implication is that all patched servers must, as a consquence, become TLS Extension tolerant, also the SSL v3-only servers. However, my feeling is that section 5 in the -01 draft is not completely clear on this; although the implication is crystal clear for renegotiation, it is IMO not clear enough for the initial handshake on a connection. I think section 5 needs to add that clients supporting RI MUST send the RI extension when it knows it is talking to a server supporting RI. The only excpetion would if the client is restricted to the no-renegotiation case in section 4, in which case it can send the MCSV to servers that are known to support RI. While it is implied by the first paragraph in sec. 5, it may also make sense to state that the client MUST use the MCSV in fallback mode, but that it does not need to send it when it is sending RI to a server known to support RI, it might actually not be necessary to send it when using the RI extension at all, since a patched server MUST support the extension. I also think that a client supporting RI which, due to fallback negotiation procedures, sent a MCSV-only handshake MUST, upon discovering that the server supports RI, terminate the connection (with a warning close notify, since it is not a real error), and re-establish the connection with a Client Hello that uses the RI extension. The reason for this will become clear below. If this is implemented, this means that all patched servers will be TLS Extension tolerant, even if the only extension they understand is the RI Extension. Given this fact, I think it would not be much of a stretch, or compliaction, since it is already part of the specification for all SSL and TLS versions, to require RI supporting servers to *properly* implement RFC 5246 section 7.4.1.3's requirement for the Server Hello: 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. and section 7.4.7.1 (RSA pre-master secret; sidenote: is it possible to implement something similar for non-RSA keyexchange?) client_version The latest (newest) version supported by the client. This is used to detect version rollback attacks. These requirements are in all versions of TLS and in SSL v3.0 (whichever draft is considered the "real" specification), and requiring correct implementation should not be controverisal (crossing fingers), and I think the RI specification should reiterate this. With such a re-iteration a separate requirement could be stated for clients: When sending the RI Extension they MUST identify the highest SSL/TLS protocol version they support, and it is a fatal error (no fallback permitted) if the server refuses to negotiate such a Hello, since such a refusal must be considered an attempt to perform a version rollback attack. Adding this requirement would close another protocol vulnerability, version rollback attacks. This type of attack is currently theorethical, since there are AFAIK no known weaknesses in SSL v3 or TLS that can realistically be leveraged if the client and server is forced to use such older protocol versions (there is the CBC attack, though), but adding this requirement will, if implemented, close the hole. It is currently trivial to force the Browser clients to perform a version rollback, due to the interoperability concerns I have mentioned before. To sum it up, my proposal is as follows: - All servers implementing the RI-spec MUST support the RI extension in Client Hello's, and therefore be extension tolerant - All servers supporting RI MUST implement the correct version negotiation method, that is, become version tolerant. - All clients supporting RI MUST send the RI extension to servers they know support RI (non-renegotiating clients excempted) - All clients supporting RI MUST specify their highest supported TLS version in the Client Hello when they are sending the RI extension. Failure to complete negotiation must be considered a fatal error and an indication of a version rollback attack on the connection; the client MUST NOT try to negotiate the connection using an older protcol version. - All clients supporting the RI Extension, but using the MCSV-only fallback Client Hello to a server that it does not know whether or not supports RI MUST shut down the connection if the server indicates RI support and re-establish the connection with RI and highest supported version number to ward off a potential version rollback attack. Failure to complete negotiate in this situation is a fatal error and must not result in a fallback. If implemented, this set of proposals will make all patched servers version and TLS extension tolerant, secure them against a possible attack method if they were not already secure against it, and remove the need for clients to support a fallback to older protocol versions once they change to a strict mode with respect to servers that have not been secured against the renegotiation attack (and as I've mentioned earlier, the effort to secure the currently existing protocol versions is wasted if such a policy change is not implemented within a reasonably short time after the RFC is published; if it isn't, this fix can just as well be implemented in TLS 1.3 instead). -- 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 ynir@checkpoint.com Sun Dec 13 00:04: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 3B7613A6806 for ; Sun, 13 Dec 2009 00:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-1.281, BAYES_50=0.001, WEIRD_PORT=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 cPJ8wTO9Hd0w for ; Sun, 13 Dec 2009 00:04:34 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E2E8A3A680C for ; Sun, 13 Dec 2009 00:04:33 -0800 (PST) X-CheckPoint: {4B249F51-10008-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 650E229C007; Sun, 13 Dec 2009 10:04:20 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3BFF829C004; Sun, 13 Dec 2009 10:04:20 +0200 (IST) X-CheckPoint: {4B249F51-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBD84KT7019427; Sun, 13 Dec 2009 10:04: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; Sun, 13 Dec 2009 10:04:31 +0200 From: Yoav Nir To: Stephen Farrell Date: Sun, 13 Dec 2009 10:04:16 +0200 Thread-Topic: [TLS] Concrete examples of TLS-intolerant servers Thread-Index: Acp7yuXrcMqfdP3hTaykSXQ9qmONIQ== Message-ID: <495B516C-03E2-41AE-BE15-E72B6D40888E@checkpoint.com> References: <4B23F022.4090303@cs.tcd.ie> In-Reply-To: <4B23F022.4090303@cs.tcd.ie> 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] Concrete examples of TLS-intolerant servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 13 Dec 2009 08:04:35 -0000 I guess it at least indicates that sites using IBM_HTTP_Server or "OracleAS= " server may have a problem unless (in the case of IBM) they're updated. Another thing is that if banks are like that, it's very likely that we'll f= ind a lot of others, in companies that don't have a "security department" l= ike banks do. On Dec 12, 2009, at 9:33 PM, Stephen Farrell wrote: >=20 > So that's 7-1 (fixed) =3D 6 extension intolerant servers out of > how many? >=20 > Hard to decide what this means otherwise. >=20 > S. >=20 > Wan-Teh Chang wrote: >> The following information was accurate as of yesterday, 2009-12-10. >> All information is public, coming from Google Chrome bug reports. >>=20 >> I identify the servers by their behavior and by the Server headers >> in the HTTP responses. >>=20 >> I tested the servers using Mac OS X 10.5 (TLS 1.0 without extensions) >> and Windows Vista (TLS 1.0 with extensions) and inspected the >> handshake messages. I didn't test TLS 1.1 or 1.2. >>=20 >> 1. https://militarybankonline.bankofamerica.com/efs/servlet/military/log= in.jsp >> "Server: IBM_HTTP_Server/6.0.2.15 Apache/2.0.47 (Unix) DAV/2" >> Intolerant of TLS extensions. Respond by closing the TCP connection >> without sending TLS alerts. >>=20 >> Update: Today (2009-12-11) this server properly ignores TLS extensions >> and identifies itself as >> "Server: IBM_HTTP_Server/6.0.2.33 Apache/2.0.47 (Unix) DAV/2" >>=20 >> 2. https://www.cdep.ro/ >> Server unknown because SSL client auth is required. >> Intolerant of TLS extensions. Respond with an illegal_parameter alert. >>=20 >> 3. https://welcome27.co-operativebank.co.uk/CBIBSWeb/start.do >> "Server: IBM_HTTP_Server" >> Intolerant of TLS extensions. Respond by closing the TCP connection >> without sending TLS alerts. >>=20 >> 4. https://stud.infostud.uniroma1.it:4445/Sest/Log/Corpo.html >> "Server: OracleAS-Web-Cache-10g/10.1.2.0.2" >> Intolerant of TLS. Respond with an (SSL 3.0) unexpected_message alert. >>=20 >> 5. https://www.bankalbilad.com.sa/retail/logon.do >> "Server: Bab web server" >> Intolerant of TLS. Respond with an (SSL 3.0) handshake_failure alert. >>=20 >> 6. Oracle Application Server >> "Server: Oracle-Application-Server-10g/10.1.2.0.2 Oracle-HTTP-Server" >> Intolerant of TLS extensions. Respond with an illegal_parameter alert. >>=20 >> 7. https://www.sbbt.com/personal-home.php >> "Server: IBM_HTTP_Server" >> Intolerant of TLS extensions. Respond by closing the TCP connection >> without sending TLS alerts. >>=20 >> Wan-Teh Chang >> _______________________________________________ >> 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 >=20 > Scanned by Check Point Total Security Gateway. From cfinss@dial.pipex.com Sun Dec 13 02: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 5A8F33A65A5 for ; Sun, 13 Dec 2009 02:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_20=-0.74, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-acT+e9USpM for ; Sun, 13 Dec 2009 02:53:30 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 6013B3A677C for ; Sun, 13 Dec 2009 02:53:30 -0800 (PST) X-Trace: 166404387/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.226/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.226 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFANNWJEs+vBHi/2dsb2JhbACCeyqFOYhqwCsKhCEE X-IronPort-AV: E=Sophos;i="4.47,390,1257120000"; d="scan'208";a="166404387" X-IP-Direction: IN Received: from 1cust226.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.226]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Dec 2009 10:53:14 +0000 Message-ID: <001801ca7bda$3492bfc0$0601a8c0@allison> From: "tom.petch" To: "Marsh Ray" , References: <200912110208.nBB28SIT024876@fs4113.wdf.sap.corp><4B21BFF5.2020909@jacaranda.org> <4B227458.9080007@extendedsubset.com> Date: Sun, 13 Dec 2009 10:43:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [TLS] Black hole was Re: Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2009 10:53:31 -0000 ----- Original Message ----- From: "Marsh Ray" To: "David-Sarah Hopwood" ; Sent: Friday, December 11, 2009 5:33 PM Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV > David-Sarah Hopwood wrote: > > > > Why? What is the point of allowing the client to send an empty extension, > > when a patched client MUST send the MSCV, and a patched server MUST use > > *only* the MSCV to determine whether the client is patched? You'd just be > > adding the option to send an extension that has no defined meaning. > > I would like for the decisions we make today to allow the MCSV hack to > be retired at some point in the future. MCSV represents extra complexity > that we added as a concession for interoperability with obsolete and > out-of-spec systems. We all have to make compromises in life and > protocol design, but it is better to do it in such a way that they > eventually pass into history rather than build up over time. > > Today there are many clients which never interoperate with > extensions-intolerant servers. If at all possible, these should have the > option of not sending the MCSV hack from the beginning. I was going to say that that logic leads me to conclude that we should not send the empty extension either. In a future version - someone suggested 3.7 :-) - the binding of renegotiation to negotiation is built in to the protocol and so no signalling - no MCSV, no RI, - nothing extra is needed in ClientHello. But while any server not supporting that version would fall back to TLS 1.somethingLess (which is the patched protocol we are now developping) and would signal in whatever way we now decide that is supports the patch, it would still need to know that this client with a version number it has never heard of also supports the patch, so the client will have to go on signalling in perpetuity. In effect, we are digging ourselves a black hole. There is a solution. We should require, as part of this patch, that upgraded stacks treat a version number that is greater than some specified value as also being a signal that the peer is upgraded. Then we will be able to drop the MCSV and/or RI as a signal from the '3.7' ClientHello. But we do need to include this now. Tom Petch > - Marsh From mickgray@au1.ibm.com Sun Dec 13 14: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 19CE33A6877 for ; Sun, 13 Dec 2009 14:26:23 -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 kRybVhoyXFw2 for ; Sun, 13 Dec 2009 14:26:22 -0800 (PST) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by core3.amsl.com (Postfix) with ESMTP id 1E7C93A63D3 for ; Sun, 13 Dec 2009 14:26:21 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp02.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBDMNNt7007159 for ; Mon, 14 Dec 2009 09:23:23 +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 nBDMMC8o1400846 for ; Mon, 14 Dec 2009 09:22:13 +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 nBDMQ6nJ032397 for ; Mon, 14 Dec 2009 09:26:06 +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 nBDMQ67w032394; Mon, 14 Dec 2009 09:26:06 +1100 In-Reply-To: <4B22E23B.4090005@jacaranda.org> To: David-Sarah Hopwood X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Mon, 14 Dec 2009 08:19:38 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 14/12/2009 09:33:08 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Closing some open comments on 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: Sun, 13 Dec 2009 22:26:23 -0000 David-Sarah Hopwood wrote: > Michael D'Errico wrote: > > Eric Rescorla wrote: > >> > >> 1. Replace "cipher suite" with magic cipher suite value (MCSV) > >> throughout. > > > > I'm not sure we want to call it "magic" in the RFC (even though I > > am probably guilty of calling it that in previous messages). > > Perhaps "special" would be a better adjective? > > Signalling cipher suite value? +1 or Probing CSV or Renegotiation CSV I also think "magic" should be avoided. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Sun Dec 13 18: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 45A083A6831 for ; Sun, 13 Dec 2009 18:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 mL5QjLNwOfoO for ; Sun, 13 Dec 2009 18:11: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 854733A676A for ; Sun, 13 Dec 2009 18:11:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBE2B3Nr017410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 03:11:03 +0100 (MET) From: Martin Rex Message-Id: <200912140211.nBE2B2rp012757@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Mon, 14 Dec 2009 03:11:02 +0100 (MET) In-Reply-To: from "Yngve N. Pettersen" at Dec 12, 9 09:01:17 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] RI, TLS Extension tolerance and version tolerance in servers 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, 14 Dec 2009 02:11:19 -0000 Yngve N. Pettersen wrote: > > I also think that a client supporting RI which, due to fallback > negotiation procedures, sent a MCSV-only handshake MUST, upon discovering > that the server supports RI, terminate the connection (with a warning > close notify, since it is not a real error), and re-establish the > connection with a Client Hello that uses the RI extension. I'm sorry, but I think that is a particularly bad idea, and completely unnecessary. In the IETF we are supposed to define and/or extend protocols in a fashion that promotes interoperability. The purpose of the MCSV is _NOT_ to prevent secure renegotiation in the fashion you describe. MCSV is the Client->Server signal that should be both usable and non-disruptive to all existing SSLv3 and TLS usage scenarios. A server that receives a ClientHello with MCSV must treat this exactly as if it had received an empty TLS extension RI. The only thing that a server needs to know for the initial handshake is that the client has been updated. It is definitely not necessary that the server asks the client to put a bow on it and retry. If that handshake is an initial handshake for the server, then the server must respond with a ServerHello containing an empty TLS extension RI. If the handshake is a renegotiation for the server, then the server must abort the handshake with a fatal handshake alert. Old servers that do _not_ need renegotiation do not need TLS extensions either. They will look purely for MCSV and return 7 extra bytes on ServerHello following compression method -- aka "RI-minimal". > > If this is implemented, this means that all patched servers will be TLS > Extension tolerant, even if the only extension they understand is the RI > Extension. There is a misunderstanding about the term "Extension tolerant". That is supposed to characterize the ClientHello forward compatibility in the 18-Nov-1996 SSLv3 document, in TLSv1.0 (rfc-2246) and TLSv1.1 (rfc-4346). It means that the server receiving data after compression_methods in ClientHello will tolerate the presence of this data, but otherwise _completely_ ignore it. The client MUST send MCSV on _every_ ClientHello, so that the Client->Server signaling completely condition-free, which will make it trivial to implement and robust. This easy rule completely obviates any talking about special cases or attack scenario. Every TLS handshake requires an initial ClientHello, and if that ClientHello always carries the Client->Server signal (which is easy to accomplish for the MCSV and non-disruptive to existing usage scenarios, then it will be completely impossible to lure an updated client into an old renegotiation with an updated server, no matter how willing client and server are to perform backwards interoperable renegotiations with old peers. -Martin From mickgray@au1.ibm.com Sun Dec 13 18: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 2474828C0EE for ; Sun, 13 Dec 2009 18:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 u8fydcqU7-PS for ; Sun, 13 Dec 2009 18:35:45 -0800 (PST) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by core3.amsl.com (Postfix) with ESMTP id CD68128C0E9 for ; Sun, 13 Dec 2009 18:35:44 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp03.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBE2Wgsb004033 for ; Mon, 14 Dec 2009 13:32:42 +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 nBE2VX4U1466604 for ; Mon, 14 Dec 2009 13:31:35 +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 nBE2ZRwB022418 for ; Mon, 14 Dec 2009 13:35:27 +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 nBE2ZRNG022415; Mon, 14 Dec 2009 13:35:27 +1100 In-Reply-To: <4B21BFF5.2020909@jacaranda.org> To: David-Sarah Hopwood X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Mon, 14 Dec 2009 12:35:10 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 14/12/2009 13:42:29 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 02:35:46 -0000 David-Sarah Hopwood wrote: > Martin Rex wrote: > > Michael Gray wrote: > >>> in order to reliably provide this, > >>> > >>> - MCSV is defined to represent an empty TLS extension RI > >>> > >>> - MSCV MUST be included in *ALL* initial ClientHello handshakes > >>> messages _plus_ all renegotiation ClientHellos in backwards > >>> interop scenarios (independent of full handshake or session resume). > >>> > >>> - empty TLS extension RI MUST NOT be sent, ever! > >> > >> This looks good to me, the only thing I would change is I think MUST NOT > >> would be better as SHOULD NOT as the later requires that the implementer > >> examine the conditions and implications etc to make the best decision. > > > > You are right. I'm sorry. I got a little carried away. > > > > A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate. > > Why? What is the point of allowing the client to send an empty extension, > when a patched client MUST send the MSCV, and a patched server MUST use > *only* the MSCV to determine whether the client is patched? You'd just be > adding the option to send an extension that has no defined meaning. > This shows how hard it is to harmonize the two proposed specs. What I want to avoid is a change to the on the wire protocol being used in production environments due to applying this fix. I see two use cases here; A. Existing implementations that send extensions today and are therefore are fine to add this additional extension. Note: this means they are already sending extensions, not just extension capable. By applying this fix nothing changes with the protocol being used. B. Existing implementations that do not send any extensions today and as such they must not change the protocol due to this fix, which means they can only safely use the MCSV as the signaling method. It seems to me that we simply need the appropriate wording to allow implementers to decide the best strategy that needs to adopted based on risk factors to deployed production environments rather than mandate A which will break some production environments or mandate B which means that extension using systems must use the CipherSuite method. Naturally requiring only one signaling method is simpler and preferable from an implementation and testing point of view. - Mick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From djhopwood@googlemail.com Sun Dec 13 19:33: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 578AB3A6996 for ; Sun, 13 Dec 2009 19:33:34 -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 JGCfYC-5+qnI for ; Sun, 13 Dec 2009 19:33:32 -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 1FCD73A698F for ; Sun, 13 Dec 2009 19:33:31 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so743836eyd.51 for ; Sun, 13 Dec 2009 19:33: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=OYPhsH1dJXP4aAAEJDSXdIZQ6OdZIwaRdAhyRfdYy8A=; b=VVCTHaKhA6Jf6HlO6ROu8zRyUozpMCvTuDhmLdwSvIARmKwCwCKosoAgDYNk8rHX99 xtTASLBWUhwZVv8RRPY+cLCs0poRHasgSV9UqjNdNv6LrejKMMgfyR9ym/gM02JM0KCC 9TlJkqJX/3eKQsupughHXjLq5RaTy7b7LA8fY= 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=WxlRGynaAZH/lwr1IobsQdBPws9rwNWXmZo+Z3BeGzkdyJVUK0QEsPPaqcnEMPNlH0 xw29YTWftlfNbtOvGAOeX0Wc9HKUlwrQEvaAyhVtII2+RowL113/BmForLQLI8tDTgcA FkSnBOA/M5X4Qzz07nBTU6EXiY0DkFgvttdEA= Received: by 10.213.104.5 with SMTP id m5mr5077614ebo.40.1260761596098; Sun, 13 Dec 2009 19:33:16 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 16sm2767378ewy.2.2009.12.13.19.33.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 13 Dec 2009 19:33:14 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B25B1F0.9010200@jacaranda.org> Date: Mon, 14 Dec 2009 03:33: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: <200912140211.nBE2B2rp012757@fs4113.wdf.sap.corp> In-Reply-To: <200912140211.nBE2B2rp012757@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4FE44672E8C6DE324FDA06C7" Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 03:33:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4FE44672E8C6DE324FDA06C7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Yngve N. Pettersen wrote: >> I also think that a client supporting RI which, due to fallback >> negotiation procedures, sent a MCSV-only handshake MUST, upon discover= ing >> that the server supports RI, terminate the connection (with a warning >> close notify, since it is not a real error), and re-establish the >> connection with a Client Hello that uses the RI extension. >=20 > I'm sorry, but I think that is a particularly bad idea, and completely > unnecessary. In the IETF we are supposed to define and/or extend > protocols in a fashion that promotes interoperability. >=20 > The purpose of the MCSV is _NOT_ to prevent secure renegotiation in the= > fashion you describe. MCSV is the Client->Server signal that should > be both usable and non-disruptive to all existing SSLv3 and TLS > usage scenarios. >=20 > A server that receives a ClientHello with MCSV must treat > this exactly as if it had received an empty TLS extension RI. >=20 > The only thing that a server needs to know for the initial handshake > is that the client has been updated. It is definitely not > necessary that the server asks the client to put a bow on it > and retry. You're missing the purpose of Yngve's suggestion, which is to prevent version rollback attacks against clients that currently do fallbacks. Suppose that the next weakness found in SSL/TLS is something that was fixed in TLS 1.0, 1.1 or 1.2. Then preventing rollback attacks will be critical, and we'll rue not having adopted Yngve's idea. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig4FE44672E8C6DE324FDA06C7 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/ iF4EAREIAAYFAkslsfwACgkQWUc8YzyzqAcU6gD/RB3oli+bpAapi/plFYa1dsk/ mkX+SQIrtQ0AGFGQ4rYA/Rg3m+RmtvngvuPXPGR6FzpLGrnyN1ddyu1a8Zjj4Hs8 =L1lA -----END PGP SIGNATURE----- --------------enig4FE44672E8C6DE324FDA06C7-- From djhopwood@googlemail.com Sun Dec 13 19: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 329D228C0EE for ; Sun, 13 Dec 2009 19: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 SdieAbfouDWR for ; Sun, 13 Dec 2009 19:39:32 -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 25C6E3A687F for ; Sun, 13 Dec 2009 19:39:31 -0800 (PST) Received: by ewy6 with SMTP id 6so1482935ewy.29 for ; Sun, 13 Dec 2009 19:39: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=6Q7vt249Y3ZXjIgpPwOQNuE5e7xjjpqtoTShVkwSCEo=; b=g99BYED/MvCdeiMDSUw5k641F/LgV7Rk3jCmLsfqUBs6S2r5iDqMtcT1gNPVDlVYdN /odLNqikpIq4/QfaXCG+lKQ7MoXSHhQQyJ73/mwAhSIcJbuLM/VuNyepX8/q4Om4Evh/ MT/qzkwWeceRkXYlEx6SWElbyqBfxWF0lNTh0= 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=FQybXGBU7lchR0r/jujSX+K+1hqT7VDqQfGRP5Y0+3LsH02ao2i1/KjSiqLDJfJTTZ 4cbNy/VwLaIboQnHNRREA/rItR/czTCanELkLJnMgvYc0lkzeQlCF6zSS9B5nu40Wtl2 sga0d7aZJIfbFxmDf2ZzXvqvEJaMwt4TTr/OQ= Received: by 10.216.90.1 with SMTP id d1mr1891012wef.136.1260761955808; Sun, 13 Dec 2009 19:39:15 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 28sm3924348eye.9.2009.12.13.19.39.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 13 Dec 2009 19:39:14 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B25B362.1020408@jacaranda.org> Date: Mon, 14 Dec 2009 03:39: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="------------enigA8C3ABFAEBAD168043256E74" Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 03:39:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA8C3ABFAEBAD168043256E74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael Gray wrote: > I see two use cases here; >=20 > A. Existing implementations that send extensions today and are therefor= e > are fine to add this additional extension. Note: this means they are > already sending extensions, not just extension capable. By applying th= is > fix nothing changes with the protocol being used. >=20 > B. Existing implementations that do not send any extensions today and a= s > such they must not change the protocol due to this fix, which means the= y > can only safely use the MCSV as the signaling method. >=20 > It seems to me that we simply need the appropriate wording to allow > implementers to decide the best strategy that needs to adopted based on= > risk factors to deployed production environments rather than mandate A > which will break some production environments or mandate B which means = that > extension using systems must use the CipherSuite method. What is the disadvantage of extension-using systems having to use the CipherSuite method? I've heard only vague aesthetic objections so far; nothing concerned with more substantive factors such as code complexity, security, or interoperability. > Naturally requiring only one signaling method is simpler and preferable= > from an implementation and testing point of view. Precisely. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigA8C3ABFAEBAD168043256E74 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/ iF4EAREIAAYFAksls2MACgkQWUc8YzyzqAdU8wD/Z9jdaOr3YtsDRFbZmQZLetet 1y1sEf7zOjhTXgBuiqEA/3Gs2PCtPL2qFKMWXm7ZuNW2C4N/a6WDNAcsskeMXKBA =HMsa -----END PGP SIGNATURE----- --------------enigA8C3ABFAEBAD168043256E74-- From mickgray@au1.ibm.com Sun Dec 13 20: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 2B40E3A683D for ; Sun, 13 Dec 2009 20:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 QamxSz1Hu6hh for ; Sun, 13 Dec 2009 20:55:39 -0800 (PST) Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by core3.amsl.com (Postfix) with ESMTP id 05FB83A67FC for ; Sun, 13 Dec 2009 20:55:38 -0800 (PST) Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp01.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBE4rfiR027843 for ; Mon, 14 Dec 2009 15:53:41 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBE4tNvT1863800 for ; Mon, 14 Dec 2009 15:55:23 +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 nBE4tNZZ027885 for ; Mon, 14 Dec 2009 15:55:23 +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 nBE4tMXl027882; Mon, 14 Dec 2009 15:55:22 +1100 In-Reply-To: <4B25B362.1020408@jacaranda.org> To: David-Sarah Hopwood X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Mon, 14 Dec 2009 14:55:08 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 14/12/2009 16:02:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 04:55:40 -0000 David-Sarah Hopwood wrote: > Michael Gray wrote: > > I see two use cases here; > > > > A. Existing implementations that send extensions today and are therefore > > are fine to add this additional extension. Note: this means they are > > already sending extensions, not just extension capable. By applying this > > fix nothing changes with the protocol being used. > > > > B. Existing implementations that do not send any extensions today and as > > such they must not change the protocol due to this fix, which means they > > can only safely use the MCSV as the signaling method. > > > > It seems to me that we simply need the appropriate wording to allow > > implementers to decide the best strategy that needs to adopted based on > > risk factors to deployed production environments rather than mandate A > > which will break some production environments or mandate B which means that > > extension using systems must use the CipherSuite method. > > What is the disadvantage of extension-using systems having to use the > CipherSuite method? I've heard only vague aesthetic objections so far; > nothing concerned with more substantive factors such as code complexity, > security, or interoperability. Yes, I do not believe a technical objection to the CipherSuite method has been presented, but rather it seems to me to be a question of technical preference. - Mick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Pasi.Eronen@nokia.com Mon Dec 14 00:25: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 582F63A6958 for ; Mon, 14 Dec 2009 00:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ON8f+OZDGpJg for ; Mon, 14 Dec 2009 00:25:31 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 43F1E3A680C for ; Mon, 14 Dec 2009 00:25:31 -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 nBE8P3RK017070 for ; Mon, 14 Dec 2009 10:25:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:25:13 +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, 14 Dec 2009 10:25:13 +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; Mon, 14 Dec 2009 09:25:12 +0100 From: To: Date: Mon, 14 Dec 2009 09:25:11 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp5I0jkyt8EuQ9iT5KPjsufPrpIgwDc3XyA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31E7F189@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E4E10.90201@cs.tcd.ie> <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> <4B1E786A.7070100@extendedsubset.com> <808FD6E27AD4884E94820BC333B2DB774F31D2391E@NOK-EUMSG-01.mgdnok.nokia.com> <4B202BCD.40500@extendedsubset.com> In-Reply-To: <4B202BCD.40500@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: 14 Dec 2009 08:25:13.0977 (UTC) FILETIME=[F5884E90:01CA7C96] X-Nokia-AV: Clean Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 08:25:32 -0000 Marsh Ray wrote: > > I guess an even worse example would be something like this: > > > > conn =3D openTlsConnection(host, port) > > if not verifyCertChain(conn.getPeerCert()): > > raise "Not a valid cert" > > if conn.getPeerCert().getName() !=3D expected_name: > > raise "Name in certificate doesn't match" > > # continue... >=20 > _After_ renegotation is fixed (and/or disabled by default) though, how > is this a problem? RI proves the data has come from the same remote > endpoint. That same remote endpoint has proven that he can supply an > acceptable cert, too. Ah -- I now see that my example was not very clear. The intent was that renegotiation happens after the first "if" statement but before the second one. So the certificate that gets used (in the 2nd "if")=20 isn't actually the one that was validated (by the 1st "if"). That would obviously be a huge security vulnerability... Best regards, Pasi (not wearing any hats) From Pasi.Eronen@nokia.com Mon Dec 14 00:31: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 B9D483A69C1 for ; Mon, 14 Dec 2009 00:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 R9fJ+BMH7Wwz for ; Mon, 14 Dec 2009 00:31:52 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 59DB63A6958 for ; Mon, 14 Dec 2009 00:31:52 -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 nBE8VTXI023281; Mon, 14 Dec 2009 10:31:36 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 10:31:34 +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, 14 Dec 2009 10:31:35 +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; Mon, 14 Dec 2009 09:31:34 +0100 From: To: Date: Mon, 14 Dec 2009 09:31:32 +0100 Thread-Topic: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV Thread-Index: Acp5s7vyPZYGFLT9QFKRnhQ1bDU+iwC40hCA Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31E7F19F@NOK-EUMSG-01.mgdnok.nokia.com> References: <4B20ABA4.3050805@extendedsubset.com> from "Marsh Ray" at Dec 10, 9 02:04:52 am <200912101613.nBAGD3X2016314@fs4113.wdf.sap.corp> In-Reply-To: <200912101613.nBAGD3X2016314@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: 14 Dec 2009 08:31:35.0261 (UTC) FILETIME=[D8CBA0D0:01CA7C97] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 08:31:53 -0000 Martin Rex wrote: > > That is interesting information. Would you happen to have a copy > > of the last "official" spec you can send me? >=20 > Netscape's official SSLv3 spec as of 2005: > http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC= .HTM No, it's not. If you look at the "SSL 3.0 Specification page"=20 back then: http://web.archive.org/web/20050210100922/http://wp.netscape.com/eng/ssl3/ It says the "most recent draft SSL 3.0 specification" is=20 http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft302= .txt which includes the "must ignore extra data" text. The version your link points to is called "previous draft of the SSL 3.0 specification". However, I don't think it's very important or interesting what Netscape considered "official" back then (and in any large company, it's quite possible that multiple opinions exist...). Much more=20 important is what the implementations still in active use do.... Best regards,=20 Pasi=20 (not wearing any hats) From yngve@opera.com Mon Dec 14 03:17: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 08E983A6983 for ; Mon, 14 Dec 2009 03:17:19 -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 JV7iudJYX84p for ; Mon, 14 Dec 2009 03:17:17 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id F1C503A67A4 for ; Mon, 14 Dec 2009 03:17:16 -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 nBEBEvEO015780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 11:14:58 GMT Date: Mon, 14 Dec 2009 12:16:58 +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: <200912140211.nBE2B2rp012757@fs4113.wdf.sap.corp> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200912140211.nBE2B2rp012757@fs4113.wdf.sap.corp> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 11:17:19 -0000 On Mon, 14 Dec 2009 03:11:02 +0100, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> I also think that a client supporting RI which, due to fallback >> negotiation procedures, sent a MCSV-only handshake MUST, upon >> discovering >> that the server supports RI, terminate the connection (with a warning >> close notify, since it is not a real error), and re-establish the >> connection with a Client Hello that uses the RI extension. > > I'm sorry, but I think that is a particularly bad idea, and completely > unnecessary. In the IETF we are supposed to define and/or extend > protocols in a fashion that promotes interoperability. Please note my pre-requisite for this suggestion: That the server MUST be Extension tolerant (preferably extension understanding, but that is beside the point in this case), and that this suggestion is mostly intended to be used in combination with the second requirement of my proposal: Version tolerance. As I said, "The reason for this will become clear below." A client that does a MCSV-only is almost certainly indicating a version less than its highest supported version, and is either doing that because it has been forced to fall back to an extensionless Hello (by intolerance, which rules out an RI capable server, based on my requirements, or by an attacker), or because the client is climbing the version ladder (like Opera), in which case it should try a higher version immediately, anyway. In combination with my suggestion of directly stating requirements on RI capabable clients and servers about which SSL/TLS version is to be sent in Client Hellos and serverside version tolerance, the MCSV-only handshake can be used to detect a version rollback attack and counter it by immediately starting to use a Client hello that states highest version. >> If this is implemented, this means that all patched servers will be TLS >> Extension tolerant, even if the only extension they understand is the RI >> Extension. > > There is a misunderstanding about the term "Extension tolerant". > That is supposed to characterize the ClientHello forward compatibility > in the 18-Nov-1996 SSLv3 document, in TLSv1.0 (rfc-2246) and > TLSv1.1 (rfc-4346). It means that the server receiving data after > compression_methods in ClientHello will tolerate the presence of > this data, but otherwise _completely_ ignore it. Maybe I should have said "understands TLS Extensions", but that is only a requirement in my proposal if MCSV is optional in an RI-hello, and my understanding of the *current* text in -01 is that the MCSV *is* optional when the RI is sent. My suggestion is to clearly enumerate the cases where it is required, and when a client MAY send it. However, I think that there is going to be very few (if any) cases where a server vendor knows in advance that the server is never going to do renegotiation and is never going to accept it. In those cases I also suspect that the vendor is also in control of the client software, and in such special cases a vendor can probably do whatever they want. In just about all other cases we will be talking about general purpose servers where it is at least conceivable that they will have to complete a renegotiation in some deployments, and in those cases the server MUST understand the RI extension, also in the initial handshake. I therefore think it is unlikely that a general purpose client will encounter a server that does not understand the RI extension, and IMO we might just as well make it a requirement that all servers MUST understand the extension. But I can live with the possibility that the MCSV have to be sent in all initial handshakes, as long as all servers MUST at least be TLS extension tolerant. The main point of my entire suggestion is that since ALL servers and clients have to be patched anyway, that the RI proposal already makes (at least) TLS tolerance a requirement, and that many servers are implemented in a fashion that forces all general clients to behave in an unsecure fashion (automatic version rollback) it would also IMO be a very good idea to close that security hole at the same time as we close the current hole, and make it very clear that the version negotiation problem will no longer be tolerated by RI capable clients. This is an opportunity to close *two* security holes at the same time, and I think we should take it. If we don't take this opportunity, we may well have to repeat the "patch all servers" routine again in, at most, a few years. I think that is an expensive way to save a few hours of checking that a few lines of code are actually doing what they should have been doing the past 15 years, and if necessary fix them. -- 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 Mon Dec 14 07: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 2E5673A6A15 for ; Mon, 14 Dec 2009 07:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 L-9NCJ5b4yxR for ; Mon, 14 Dec 2009 07:40: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 D6F3C3A6A13 for ; Mon, 14 Dec 2009 07:40:19 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBEFe4dK026530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 16:40:04 +0100 (MET) From: Martin Rex Message-Id: <200912141540.nBEFe3km002000@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Mon, 14 Dec 2009 16:40:03 +0100 (MET) In-Reply-To: from "Yngve N. Pettersen" at Dec 14, 9 12:16: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] RI, TLS Extension tolerance and version tolerance 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: Mon, 14 Dec 2009 15:40:21 -0000 Yngve N. Pettersen wrote: > > A client that does a MCSV-only is almost certainly indicating a version > less than its highest supported version, and is either doing that because > it has been forced to fall back to an extensionless Hello (by intolerance, > which rules out an RI capable server, based on my requirements, or by an > attacker), or because the client is climbing the version ladder (like > Opera), in which case it should try a higher version immediately, anyway. > > In combination with my suggestion of directly stating requirements on RI > capabable clients and servers about which SSL/TLS version is to be sent in > Client Hellos and serverside version tolerance, the MCSV-only handshake > can be used to detect a version rollback attack and counter it by > immediately starting to use a Client hello that states highest version. This sound somewhat inconclusive to me. If it is possible to force a client to perform a re-connect fallback, then we can not provide any protection against this at the TLS protocol level. The purpose of MCSV is to provide protection from insecure renegotiation between updated TLS peers even for fallback-scenarios, so there is nothing that needs to be done for the secure TLS renegotiation part. Since we are, in fact, suggesting SSLv3 servers to add the renegotiation protection patch as well, it would be a flawed assumption that a server would select newer protocol features if the client had simply sent a more feature-rich ClientHello. In probabilistic terms, it might, but since you are talking about a client that will use a feature-rich ClientHello as default and what you described would only apply to the fallback scenario, then most of the time this will be simply an old server. The majority of programmatic clients likely do not have any app-level retry logic and neither do they keep lists of servers an the TLS features these support in order to optimize their app-level retry logic. Usually, those clients just want conservative protocol defaults for their ClientHello so that they have a high likelyhood to obtain interoperability with most of the installed base. > > I therefore think it is unlikely that a general purpose client will > encounter a server that does not understand the RI extension, and IMO we > might just as well make it a requirement that all servers MUST understand > the extension. But I can live with the possibility that the MCSV have to > be sent in all initial handshakes, as long as all servers MUST at least be > TLS extension tolerant. To get rid of complexity, the empty TLS extension RI for ClientHello should be completely removed from the specification (i.e. MUST be ignored by servers if present). Implementation-wise it will be even simpler and more robust, if MCSV is sent on every renegotiation handshake as well (i.e. unconditionally included in all ClientHellos), even when there is an accompanying TLS extension RI with Client.Finished.verify_data. This will facilitate code that allows backwards interoperable renegotiation (server-side). If either the current session is already marked for secure renegotiation or the incoming ClientHello carries the MCSV, then the strict rules for secure renegotiation processing apply, no matter how willing the server is to perform old renegotiation based on its configuration (admin requirement). > > The main point of my entire suggestion is that since ALL servers and > clients have to be patched anyway, that the RI proposal already makes (at > least) TLS tolerance a requirement, and that many servers are implemented > in a fashion that forces all general clients to behave in an unsecure > fashion (automatic version rollback) it would also IMO be a very good idea > to close that security hole at the same time as we close the current hole, > and make it very clear that the version negotiation problem will no longer > be tolerated by RI capable clients. Some server will not be patched, and for a non-negligable time we will have a mix of old and updated peers out there, and every day some more of the old will become updated. > > This is an opportunity to close *two* security holes at the same time, and > I think we should take it. *I* would not refer to the fallback re-try logic in your Browser as a security hole. It definitely does not need to be one, and it's completely up to your implementation to ensure that. Your idea is an expensive mitigation strategy at best (security by obscurity). If you really wanted to improve that, then it might be an idea to signal back to the client the highest supported SSL/TLS protocol version of the server along with the currently empty TLS extension RI -- and make the initial TLS handshake complete(!) (only when the handshake is completed successfully, the information exchanged during the TLS handshake is authenticated. Most clients do not intend to renegotiate the session themselves, and the majority of programmatic clients is unlikely to cache/memorize such data returned by the server for future TLS sessions. > > If we don't take this opportunity, we may well have to repeat the "patch > all servers" routine again in, at most, a few years. I don't understand what you are refering to. The issue that maintenance folks should check, when they touch any old code, is what I described in Appendix A.1 of my I-D. -Martin From gajek@post.tau.ac.il Mon Dec 14 07:42: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 E29A028C126 for ; Mon, 14 Dec 2009 07:42:54 -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 aOan3wrQmKZA for ; Mon, 14 Dec 2009 07:42:53 -0800 (PST) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id 6634028C124 for ; Mon, 14 Dec 2009 07:42:52 -0800 (PST) Received: from [192.168.0.25] (85.64.127.18.dynamic.barak-online.net [85.64.127.18]) by doar.tau.ac.il (Postfix) with ESMTP id 40D5CBEFA for ; Mon, 14 Dec 2009 17:42:38 +0200 (IST) User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Mon, 14 Dec 2009 17:42:06 +0200 From: Sebastian Gajek To: Message-ID: Thread-Topic: Closing some open comments on draft-ietf-tls-renegotiation Thread-Index: Acp80/0d4zm97OCPEkiT1QBeYxZnuQ== Mime-version: 1.0 Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3343657326_5270230" X-Mailman-Approved-At: Mon, 14 Dec 2009 07:52:14 -0800 Subject: [TLS] Closing some open comments on 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, 14 Dec 2009 15:44:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3343657326_5270230 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi there, sorry for putting another mail into the long list of TLS renegotiation mails. I skimmed the TLS-renegotiation draft. Surely, a countermeasure is to cryptographically link the TLS sessions. There are different approaches to achieve this goal. I was wondering why you introduce a new cipher suite. Wouldn't it be easier to require that finished values are a function of all values received so far (incl. previous TLS sessions or at least their finished values.) This countermeasure is simple, complies with the present TLS spec and could result in faster adaption. Is there a technicality I am not aware? Thx for any feedback. -- Sebastian Gajek School of Computer Science Tel Aviv University, Israel Web: http://www.cs.tau.ac.il/~gajek/ --B_3343657326_5270230 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIL6QYJKoZIhvcNAQcCoIIL2jCCC9YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CZwwggTFMIIELqADAgECAg49SgABAAL2AZ+fCLqHHDANBgkqhkiG9w0BAQUFADB8MQswCQYD VQQGEwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1 c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQSBWSTAeFw0wOTA4MTExMjUzMDBaFw0xMDA4MTIxMjUzMDBaMEwxCzAJBgNVBAYT AklMMRgwFgYDVQQDEw9TZWJhc3RpYW4gR2FqZWsxIzAhBgkqhkiG9w0BCQEWFGdhamVrQHBv c3QudGF1LmFjLmlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1oOc03EOCMfs hP83MB4jl1mf40ym4TGyZe5SjG2o8l2G1NS735XdjUjGbWoONGvQ1J2Iqs2GFVWNoR4TWjPh N7SSx8bqU/w9cvWrAeimk+GIRLmQNBSTL2bBVv3WcTnHHMbJ+zoR+7j9FuxxtZbY83yhdda2 dMJGaY1NkiTVlNfcNqGzX5Iy0ZN+u8KTaGKIAGB6dVyBlmKUUNrL2YK9XlHhvHjhRo5MZMVV UnR7fIMBhHzac9zqAADn05p5SAMDckTsZAuKpAmnPlXeJOHearfWJyM7nbTW33lxsOpkEn45 pfjdPwkLdBvBxNjfQOuUFkcbF5IHrsuIFcJ0ibFWawIDAQABo4IB9DCCAfAwgZcGCCsGAQUF BwEBBIGKMIGHMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NlcnRz ZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9WSS5jcnQwMgYIKwYBBQUHMAGGJmh0 dHA6Ly9vY3NwLlZJLnRjY2xhc3MxLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFE6b9bL7 3Wpr3EoHr8m7ZP8WSyafMAwGA1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEw MjAwBggrBgEFBQcCARYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4G A1UdDwEB/wQEAwIE8DAdBgNVHQ4EFgQU/MTk7LaDw+3M5W50cx2epld9y14wVAYDVR0fBE0w SzBJoEegRYZDaHR0cDovL2NybC5WSS50Y2NsYXNzMS50cnVzdGNlbnRlci5kZS9jcmwvdjIv dGNfY2xhc3MxX0wxX0NBX1ZJLmNybDAzBgNVHSUELDAqBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHBgorBgEEAYI3FAICMB8GA1UdEQQYMBaBFGdhamVrQHBvc3QudGF1LmFjLmls MA0GCSqGSIb3DQEBBQUAA4GBACQtYOhTK/tRjEa/fZcMeVVcTVco1qQP4jWBLDY7ZDymT+6Q 4u0MAT4C/YkJBNNWO3Q00F/kyUyJ/GgYYwQ8sYQl3JYMvXXySKasqMCky0wxQ49Lhaz58GKf HOUSxB9UZufN5p+z7Fz17c02GZn+/CDeDs9ADE1tGDWRP4g1p8+6MIIEzzCCBDigAwIBAgIP AJSwAAEAAmKNtR9u7HJkMA0GCSqGSIb3DQEBBQUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UE CBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIg Zm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50 ZXIuZGUwHhcNMDgwNzE4MTEzODU0WhcNMTAxMjMxMjI1OTU5WjB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIg Q2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBW STCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAlAU/f06WxH4Ws7qwgLm3H6TdpOOwvigI uuyt3Zn2dUzOsfGe9KGWbEuGASUVOEihHOjuCvWZlvHb8a7dfnVIQE1OQ/dtXZTSOf3LEaj3 uhhYD/5xFQoQSzF+9s9fkMv33YS6lwSm1ABW62bfayjd0aL6ep7aYVfDHzCkMCcKQNECAwEA AaOCAhAwggIMMIGOBggrBgEFBQcBAQSBgTB/MEwGCCsGAQUFBzAChkBodHRwOi8vd3d3LnRy dXN0Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzXzFfY2EuY3J0MC8G CCsGAQUFBzABhiNodHRwOi8vb2NzcC50Y2NsYXNzMS50cnVzdGNlbnRlci5kZTAPBgNVHRMB Af8EBTADAQH/MEoGA1UdIARDMEEwPwYJKoIUACwBAQEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6 Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0O BBYEFE6b9bL73Wpr3EoHr8m7ZP8WSyafMIHsBgNVHR8EgeQwgeEwgd6ggduggdiGO2h0dHA6 Ly9jcmwudGNjbGFzczEudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX2NsYXNzXzFfY2EuY3Js hoGYbGRhcDovL3d3dy50cnVzdGNlbnRlci5kZS9DTj1UQyUyMFRydXN0Q2VudGVyJTIwQ2xh c3MlMjAxJTIwQ0EsTz1UQyUyMFRydXN0Q2VudGVyJTIwQUcsb3U9cm9vdGNlcnRzLGRjPXRy dXN0Y2VudGVyLGRjPWRlP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT8wDQYJKoZI hvcNAQEFBQADgYEAbgCkuWfdEuoOLKaN2TxIWzxLppxCvKuRkH8MnZAfqf7otioSOKuH79mP y7B5Avqnp32D92XhLXCkgYJULfcB1wzyp6v8KfSpxDpt1256x9Nx1C/m5mVKzIR0o1rjgNW0 6HciRMu0V1wOJji1AWuIzuRULle6HJ/GjnxXW84zyv4xggIVMIICEQIBATCBjjB8MQswCQYD VQQGEwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1 c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQSBWSQIOPUoAAQAC9gGfnwi6hxwwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBSzDIKn8dwdLkoYDMfILGBqUrU6WTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wOTEyMTQxNTQyMDZaMA0GCSqGSIb3DQEBAQUABIIBAEI9MknbNVHLzga3 RP720+GIWHmYnhnTHXGfJ/idvCuJIgQ60Ry2/jDuBfOqEe6pP98EE927lgLWC/QIsdcOGklE DZYiMmT00CvxKD/Yaw2spGBTaHXlMAme7J3NJL8QrHFg9WU+rW74QwiZnatPcVwu7Ab9dtiy 7plx7aFG4ZaLJX9LmslR3mxn7uUOBJMPbr6sMZYHQf9iUlrst0UTrwHTo+hBOrF/4L7N8nX+ vlaN/pXOgdqfVkrXYRqkZS3WaANAXCCaui2d3brvsS0ZIw/URU93Sl1D2PB6/8lrl+CWzQHh tIxvzTpBPHZeeQc5hH8iJ5yLVEDRIcquLzkxUHc= --B_3343657326_5270230-- From mrex@sap.com Mon Dec 14 07:54: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 E3ACA3A6881 for ; Mon, 14 Dec 2009 07:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 DpPTi+cOhfUR for ; Mon, 14 Dec 2009 07: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 DE7763A67EB for ; Mon, 14 Dec 2009 07:54:43 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBEFsPA9015313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 16:54:25 +0100 (MET) From: Martin Rex Message-Id: <200912141554.nBEFsODa002884@fs4113.wdf.sap.corp> To: cfinss@dial.pipex.com Date: Mon, 14 Dec 2009 16:54:24 +0100 (MET) In-Reply-To: <001801ca7bda$3492bfc0$0601a8c0@allison> from "tom.petch" at Dec 13, 9 10:43:00 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] Black hole was Re: Analysis of Interop scenarios TLS 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, 14 Dec 2009 15:54:45 -0000 tom.petch wrote: > > There is a solution. We should require, as part of this patch, that upgraded > stacks treat a version number that is greater than some specified value as > also being a signal that the peer is upgraded. Then we will be able to drop > the MCSV and/or RI as a signal from the '3.7' ClientHello. But we do need > to include this now. In theory, you are correct. This would, however, require us to effectively standarize the secure TLS renegotiation for TLSv1.3 (or some specific TLS version in the future) ahead of time. The decision for the server would be easy, since it knows both protocol version values (the ClientHello.client_version and his own max. supported value) after processing ClientHello. The decision for the client is more difficult on the initial connect, when it doesn't know yet whether the server will understand it, and this problem remains on the renegotiation handshake, where an MitM attacker might proxy the renegotiation handshake into an initial or renegotiation handshake of an older server. One could define my draft-mrex-tls-secure-renegotiation-03 to become standard with TLSv1.3 and have it grow out of the installed base naturally, because it changes the handshake message hash, and prevents you from proxying a new (both initial and renegotiation) handshake from proxying into handshakes of old servers. TLS extension RI, on the other hand, does _not_ change the handshake message hash, so you will have to keep that band-aid around for as long as you _allow_ interop with TLSv1.2 or below, no matter what TLS WG defines and implements in newer protocol versions. Therefore TLS extension RI is tomorrows cruft. -Martin From yngve@opera.com Mon Dec 14 09:00: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 BA34B3A68FB for ; Mon, 14 Dec 2009 09:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 bmtUlVoftKvR for ; Mon, 14 Dec 2009 09:00:09 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 87E473A6A29 for ; Mon, 14 Dec 2009 09:00:09 -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 nBEGvopX001896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 16:57:51 GMT Date: Mon, 14 Dec 2009 17:59:54 +0100 To: 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: <200912141540.nBEFe3km002000@fs4113.wdf.sap.corp> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200912141540.nBEFe3km002000@fs4113.wdf.sap.corp> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in 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, 14 Dec 2009 17:00:12 -0000 On Mon, 14 Dec 2009 16:40:03 +0100, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> A client that does a MCSV-only is almost certainly indicating a version >> less than its highest supported version, and is either doing that >> because >> it has been forced to fall back to an extensionless Hello (by >> intolerance, >> which rules out an RI capable server, based on my requirements, or by an >> attacker), or because the client is climbing the version ladder (like >> Opera), in which case it should try a higher version immediately, >> anyway. >> >> In combination with my suggestion of directly stating requirements on RI >> capabable clients and servers about which SSL/TLS version is to be sent >> in >> Client Hellos and serverside version tolerance, the MCSV-only handshake >> can be used to detect a version rollback attack and counter it by >> immediately starting to use a Client hello that states highest version. > > > This sound somewhat inconclusive to me. If it is possible to force > a client to perform a re-connect fallback, then we can not provide any > protection against this at the TLS protocol level. The purpose of MCSV > is to provide protection from insecure renegotiation between updated > TLS peers even for fallback-scenarios, so there is nothing that > needs to be done for the secure TLS renegotiation part. I am talking about a client, as all current Browser clients, that have to allow the use of non-extension handshakes because of interoperability reasons. In that *particular* situation, when it does not know that it is about to talk to an RI patched server. Upon discovering that it is indeed RI patched, based on my suggestions for requireiement the client knows two additional things: 1) It can use the RI extension with this server, and 2) it have to make sure that it was not forced to use an older SSL/TLS version than it supports. Therefore it should tear down the connection and re-establish it, in Opera's case signalling support for TLS 1.2 and using the RI extension, and (again assuming my proposal is accepted) the server will accept the hello, respond with a RI extension and its highest supported version if it is lower than Opera's, and Opera's if the server supports a newer version. If the handshake fails in this situation somebody is trying to perform a version rollback attack against the client. > > Since we are, in fact, suggesting SSLv3 servers to add the renegotiation > protection patch as well, it would be a flawed assumption that a > server would select newer protocol features if the client had simply > sent a more feature-rich ClientHello. In probabilistic terms, it > might, but since you are talking about a client that will use a > feature-rich ClientHello as default and what you described would only > apply to the fallback scenario, then most of the time this will be > simply an old server. The SSL v3 server does not have to select newer protocol features, it just have to *tolerate* that the client uses them. If the server supports renegotiation it will have to implement support for the extension, and it have to be flexible enough to handle whatever syntactically correct extension list the client sends. If the server does not support renegotiation then it might not support the extension, but my proposal is that it MUST be TLS Extension *tolerant*. I am however suggestion, optionally, that supporting the extension should be a MUST in patched servers. > The majority of programmatic clients likely do not have any app-level > retry logic and neither do they keep lists of servers an the TLS features > these support in order to optimize their app-level retry logic. > Usually, those clients just want conservative protocol defaults > for their ClientHello so that they have a high likelyhood to > obtain interoperability with most of the installed base. I am not talking applevel, I am saying that the SSL/TLS implementation must restart the connection. The case where that may cause problems, is for upgradeable protocols features like SMTP STARTTLS, and I assume that all those clients either already have a fallback mechanism that requires restart and have an application layer that can handle that, or they signal their highest version and uses extension (if they support it) all the time, and expect the server to tolerate it. If it is desirable to avoid restarts, the simple way to handle that is to signal highest version and the extension, and require the server to handle it. >> I therefore think it is unlikely that a general purpose client will >> encounter a server that does not understand the RI extension, and IMO we >> might just as well make it a requirement that all servers MUST >> understand >> the extension. But I can live with the possibility that the MCSV have to >> be sent in all initial handshakes, as long as all servers MUST at least >> be >> TLS extension tolerant. > > To get rid of complexity, the empty TLS extension RI for ClientHello > should be completely removed from the specification (i.e. MUST be ignored > by servers if present). I disagree. The empty RI should be the default, and the MCSV only used when a *lenient* client connects to an *unknown* server, optionally using a fallback to a configuration that does not support extensions. > Implementation-wise it will be even simpler and more robust, > if MCSV is sent on every renegotiation handshake as well I am working within the framework of EKR's document. > (i.e. unconditionally included in all ClientHellos), even when > there is an accompanying TLS extension RI with > Client.Finished.verify_data. My suggestion does not really touch on that scenario, but my recommendation is that the MCSV in only sent in the initial handshake, but as long as clients are lenient they may send it in any handshake. Strict clients should only use handshakes with the extension, and identifying the highest supported version. MVCS should only be used in this case if support for the extension is optional in servers that does not support renegotiation, but I think that is going to be such a limited amount of instances that it is better to require extension support in all servers. > This will facilitate code that allows backwards interoperable > renegotiation (server-side). If either the current session is > already marked for secure renegotiation or the incoming ClientHello > carries the MCSV, then the strict rules for secure renegotiation > processing apply, no matter how willing the server is to perform > old renegotiation based on its configuration (admin requirement). > > >> >> The main point of my entire suggestion is that since ALL servers and >> clients have to be patched anyway, that the RI proposal already makes >> (at >> least) TLS tolerance a requirement, and that many servers are >> implemented >> in a fashion that forces all general clients to behave in an unsecure >> fashion (automatic version rollback) it would also IMO be a very good >> idea >> to close that security hole at the same time as we close the current >> hole, >> and make it very clear that the version negotiation problem will no >> longer >> be tolerated by RI capable clients. > > Some server will not be patched, and for a non-negligable time we will > have a mix of old and updated peers out there, and every day some more of > the old will become updated. My position is that the time for changeover before clients turn strict should be no more than 12 months, preferably less. If we allow a more extendend period for upgrades we can just as well drop the current discussion and start working on fixing it in TLS 1.3 instead, we won't possibly be able to turn strict before that protocol version is widely deployed in year 2020 or 2025. >> This is an opportunity to close *two* security holes at the same time, >> and >> I think we should take it. > > *I* would not refer to the fallback re-try logic in your Browser as > a security hole. It definitely does not need to be one, and it's > completely up to your implementation to ensure that. It is *impossible* for such fallback code to determine if the server is broken or there is an attack going. To interoperate we have had to open a security hole, and it is time and more than time to close it permanently. As it sounds like you may have a way to determine if a connection shutdown, no response withing a timout, or a finished message that fails is due to a server implementation "mistake", and is not an attack intended to force me to use an older version of the protocol, perhaps you can provide more details? > Your idea is an expensive mitigation strategy at best Expensive? Making sure an if-then-else clause and a variable check is correct should not be expensive, nor should fixing it be expensive either. The servers have to be fixed anyway. > (security by obscurity). If you really wanted to improve that, then > it might be an idea to signal back to the client the highest supported > SSL/TLS protocol version of the server along with the currently > empty TLS extension RI -- and make the initial TLS handshake complete(!) > (only when the handshake is completed successfully, the information > exchanged during the TLS handshake is authenticated. There is already a way for that signal: The client signal its highest version, the server selects the lowest of its version and the client's stated version, and in RSA also double check this with the version number in the RSA Premaster Secret. There is no need for a more complex signal; we just have to fix the broken servers that insist that clients can't use a higher protocol version than the one they use. >> If we don't take this opportunity, we may well have to repeat the "patch >> all servers" routine again in, at most, a few years. > > I don't understand what you are refering to. What I am saying is that it is conceivable that we could have a break in, for example, SSL v3 that makes a live attack on the protocol feasible, but only if it can trick the client and server to negotiate a SSL v3.0 connection, and today that is *trivial*; all major clients do it *automatically*! Once that news reach the community there will be a mad scramble to disable SSLv3 in servers and clients, and to disable the fallback. Let's not wait for that to happen, let's avoid that scramble, let's remove the very reason why we need a fallback, at least in strict clients and against known RI-patched servers, and let's do it *now*. -- 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 Mon Dec 14 11:12: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 AAC3F3A690C for ; Mon, 14 Dec 2009 11:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.778 X-Spam-Level: X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[AWL=-0.362, 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 CPk61BIoMden for ; Mon, 14 Dec 2009 11:12: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 851643A690B for ; Mon, 14 Dec 2009 11:12:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBEJBnub003794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 20:11:49 +0100 (MET) From: Martin Rex Message-Id: <200912141911.nBEJBmMr014961@fs4113.wdf.sap.corp> To: yngve@opera.com Date: Mon, 14 Dec 2009 20:11:48 +0100 (MET) In-Reply-To: from "Yngve Nysaeter Pettersen" at Dec 14, 9 05:59: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] RI, TLS Extension tolerance and version tolerance 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: Mon, 14 Dec 2009 19:12:07 -0000 Yngve Nysaeter Pettersen wrote: > > I am talking about a client, as all current Browser clients, that have to > allow the use of non-extension handshakes because of interoperability > reasons. > > In that *particular* situation, when it does not know that it is about to > talk to an RI patched server. Upon discovering that it is indeed RI > patched, based on my suggestions for requireiement the client knows two > additional things: 1) It can use the RI extension with this server, and 2) > it have to make sure that it was not forced to use an older SSL/TLS > version than it supports. Therefore it should tear down the connection and > re-establish it, in Opera's case signalling support for TLS 1.2 and using > the RI extension, and (again assuming my proposal is accepted) the server > will accept the hello, respond with a RI extension and its highest > supported version if it is lower than Opera's, and Opera's if the server > supports a newer version. If the handshake fails in this situation > somebody is trying to perform a version rollback attack against the client. That is _not_ a version rollback attack (on the TLS protocol version), but instead a downgrade attack on your fallback logic. It is unrelated to the TLS renegotiation vulnerability. > > I am not talking applevel, I am saying that the SSL/TLS implementation > must restart the connection. Going through a handshake failure would be a fairly broken solution an can not possibly work at the TLS protocol level. What you could use is either the MS SGC logic (which internally restarts the handshake mid-way), or successfully complete the handshake and renegotiate immediately after with better features. Any form of handshake failure, reconnect and new handshake will require apps-level support for this. Quite a number of TLS implementations do not include transport, and even those that include transport can usually not perform a re-connect all by themselves. (How many TLS implementations perform things like a HTTP CONNECT proxy traversal all by themselves, instead of getting an established network connection handle where they should start a TLS handshake? > > The case where that may cause problems, is > for upgradeable protocols features like SMTP STARTTLS, and I assume that > all those clients either already have a fallback mechanism that requires > restart and have an application layer that can handle that, or they signal > their highest version and uses extension (if they support it) all the > time, and expect the server to tolerate it. I assume that few, if any, have a fallback retry logic. They usually may have a possibility to select a protocol version upfront (SSLv2, SSLv3, TLSv1), and depending on their age (or more precisely the age of their TLS implementation), might not be using TLS extensions so far, even when TLSv1 is selected. The "canonical" clients would be "curl" and WinHTTP. Which one of these currently has a fallback retry logic? > > If it is desirable to avoid restarts, the simple way to handle that is to > signal highest version and the extension, and require the server to handle > it. You can implement whatever fancy fallback logic you like in your TLS clients. Just make sure you do not end up in a deadly embace. (that might be particularly bad for mobile customers of the Opera browser which pay-per-volume). IMHO, Nothing of this belongs into a secure TLS renegotiation solution. > > >> I therefore think it is unlikely that a general purpose client will > >> encounter a server that does not understand the RI extension, and IMO we > >> might just as well make it a requirement that all servers MUST > >> understand > >> the extension. But I can live with the possibility that the MCSV have to > >> be sent in all initial handshakes, as long as all servers MUST at least > >> be > >> TLS extension tolerant. > > > > To get rid of complexity, the empty TLS extension RI for ClientHello > > should be completely removed from the specification (i.e. MUST be ignored > > by servers if present). > > I disagree. The empty RI should be the default, and the MCSV only used > when a *lenient* client connects to an *unknown* server, optionally using > a fallback to a configuration that does not support extensions. That would be adding unnecessary complexity without value. Either you do not need MCSV, then you should get rid of that, or you need MCSV, then you should get rid of empty TLS extension RI _in_the_ClientHello_. Having both is a completely unnecessary complexity, requires extra code, extra testing, will lead to extra bugs and amounts to pure waste. > > > Implementation-wise it will be even simpler and more robust, > > if MCSV is sent on every renegotiation handshake as well > > I am working within the framework of EKR's document. Me 2. > > > (i.e. unconditionally included in all ClientHellos), even when > > there is an accompanying TLS extension RI with > > Client.Finished.verify_data. > > My suggestion does not really touch on that scenario, but my > recommendation is that the MCSV in only sent in the initial handshake, but > as long as clients are lenient they may send it in any handshake. If the solution needs to distinguish special cases or scenarios, then it is way to complex. Every conditional in your description creates at least one additional conditional in the code (often more), which increases code size and complexity, requires additional test cases and make the solution worse. > > My position is that the time for changeover before clients turn strict > should be no more than 12 months, preferably less. Btw. I still haven't understood what the "lenient client" and "lenient servers" are that some people have been refering to. Possible backwards interop scenarios are the following: 1. updated client allowing initial handshake with old server 2. updated client allowing renegotiation handshake with old server 3. updated server allowing initial handshake with old client 4. updated server allowing renegotiation handshake with old client The one we _need_ to get rid of is (4), the one we hope to get rid of after transistion is (2). (1) and (3) will likely need to be around _much_ longer than 12 months. > > > > > *I* would not refer to the fallback re-try logic in your Browser as > > a security hole. It definitely does not need to be one, and it's > > completely up to your implementation to ensure that. > > It is *impossible* for such fallback code to determine if the server is > broken or there is an attack going. To interoperate we have had to open a > security hole, and it is time and more than time to close it permanently. If you think it is a security hole, then you are free to disable it _in_your_implementation_. Personally, I do not think there currently is a known serious security problem with an extension-less SSLv3 ClientHello. > > > Your idea is an expensive mitigation strategy at best > > Expensive? Making sure an if-then-else clause and a variable check is > correct should not be expensive, nor should fixing it be expensive either. > The servers have to be fixed anyway. It is also expensive in terms of testing an extra code path, in particular if you have a dozen or more seperate codelines unter maintenance, but I was rather refering to network overhead --a full new connection setup overhead, which may involve TCP 3-way handshake and whatever apps-protocol overhead is prefixed to the TLS communication plus the network data, which may result in a significant extra latency on connection setup (as seen by the app). > > There is already a way for that signal: The client signal its highest > version, the server selects the lowest of its version and the client's > stated version, and in RSA also double check this with the version number > in the RSA Premaster Secret. No, there is not. You mentioned it yourself, that in your fallback you will send a low protocol version number in ClientHello.client_version (maybe even { 0x03, 0x00 }, which is why you came up with the fancy ideas to close the connection and retry -- simply because you do _not_ know the highest protocol version that the server actually supports. The poor interoperability of newer TLS protocol versions with the installed base goofs the entire "version rollback protection" design in the original protocol. The client has simply no idea whether the server is doing a good choice when selecting a common protocol version or a common cipher suite (some servers actually seem to be doing a poor job at selecting ciphers suites). > > What I am saying is that it is conceivable that we could have a break in, > for example, SSL v3 that makes a live attack on the protocol feasible, but > only if it can trick the client and server to negotiate a SSL v3.0 > connection, and today that is *trivial*; all major clients do it > *automatically*! Once that news reach the community there will be a mad > scramble to disable SSLv3 in servers and clients, and to disable the > fallback. I'm sorry, I don't see that problem. The Browsers I have, even those as old as MSIE 6 on Windows XP let me disable SSLv3 support if I want to. Maybe there is a problem in your _implementation_ ? Btw. I observed that MSIE 7+ on Vista will not allow AES ciphersuites (rfc-3268) to be negotiated for SSLv3. I know that it is not specified to apply to SSLv3, but that does not mean that it could not be used there. Firefox seems to tolerate AES ciphersuites in combination with protocol version { 0x03, 0x00 }. -Martin From wwwrun@core3.amsl.com Mon Dec 14 11:20:00 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 427A53A6A27; Mon, 14 Dec 2009 11:19:57 -0800 (PST) From: Russ Housley To: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091214191959.427A53A6A27@core3.amsl.com> Date: Mon, 14 Dec 2009 11:19:57 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] COMMENT: 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, 14 Dec 2009 19:20:00 -0000 Comment: As a protocol climbs the IETF standards-track maturity ladder, we sometimes drop features. I would rather see renegotiation dropped from TLS than see this complexity added to TLS protocol. From smb@cs.columbia.edu Mon Dec 14 11: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 E1E013A6827; Mon, 14 Dec 2009 11: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 7jwZgecpDd+Z; Mon, 14 Dec 2009 11:44:38 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id DD5013A6820; Mon, 14 Dec 2009 11:44:37 -0800 (PST) Received: from mallet.cs.columbia.edu (mallet.cs.columbia.edu [128.59.21.121]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBEJiOrA019308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Dec 2009 14:44:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <20091214191959.427A53A6A27@core3.amsl.com> Date: Mon, 14 Dec 2009 14:44:23 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20091214191959.427A53A6A27@core3.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 14 Dec 2009 19:44:39 -0000 On Dec 14, 2009, at 2:19 PM, Russ Housley wrote: > Comment: > > As a protocol climbs the IETF standards-track maturity ladder, we > sometimes drop features. I would rather see renegotiation dropped > from TLS than see this complexity added to TLS protocol. Works for me. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Nicolas.Williams@sun.com Mon Dec 14 11:52: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 2AEFE28C169; Mon, 14 Dec 2009 11:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.129, 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 QcZuYyXY6HPs; Mon, 14 Dec 2009 11:52:16 -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 0C20A28C161; Mon, 14 Dec 2009 11:52:16 -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 nBEJq23j025747; Mon, 14 Dec 2009 19:52: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 nBEJq2Iw063986; Mon, 14 Dec 2009 12:52: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 nBEJiWaD004428; Mon, 14 Dec 2009 13:44:32 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBEJiWQI004427; Mon, 14 Dec 2009 13:44:32 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 14 Dec 2009 13:44:32 -0600 From: Nicolas Williams To: Russ Housley Message-ID: <20091214194431.GO1516@Sun.COM> References: <20091214191959.427A53A6A27@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091214191959.427A53A6A27@core3.amsl.com> User-Agent: Mutt/1.5.7i Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 14 Dec 2009 19:52:17 -0000 On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote: > As a protocol climbs the IETF standards-track maturity ladder, we > sometimes drop features. I would rather see renegotiation dropped > from TLS than see this complexity added to TLS protocol. I would like to agree. There's no real-world need to re-negotiate for re-keying nowadays: with the advent of 128-bit block block ciphers there's little need. But re-negotiation remains useful for other purposes. Probably the most obvious ones are optional authentication and privacy protection for client credentials. I'm not sure those are sufficiently useful or important to warrant keeping the feature, but if not then dropping the feature does seem like a better option than fixing it. Nico -- From housley@vigilsec.com Mon Dec 14 11:52:30 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C5328C150; Mon, 14 Dec 2009 11:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 JPKtOJDjvGeM; Mon, 14 Dec 2009 11:52:29 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 853C63A68C5; Mon, 14 Dec 2009 11:52:29 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 2BAA1F2402D; Mon, 14 Dec 2009 14:52:31 -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 uV-cyQLCFeWQ; Mon, 14 Dec 2009 14:52:15 -0500 (EST) Received: from THINKPADR52.vigilsec.com (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 74C12F24001; Mon, 14 Dec 2009 14:52:30 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Dec 2009 14:52:14 -0500 To: iesg@ietf.org From: Russ Housley In-Reply-To: <20091214191959.427A53A6A27@core3.amsl.com> References: <20091214191959.427A53A6A27@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091214195230.74C12F24001@odin.smetech.net> Cc: tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 14 Dec 2009 19:52:30 -0000 This message was sent by the Datatracker when I entered an ABSTAIN ballot position on this document. I am not blocking the approval or the progression of this document. However, I cannot support it either. I am simply documenting the reason for the ABSTAIN ballot position. Russ At 02:19 PM 12/14/2009, Russ Housley wrote: >Comment: > > As a protocol climbs the IETF standards-track maturity ladder, we > sometimes drop features. I would rather see renegotiation dropped > from TLS than see this complexity added to TLS protocol. From mrex@sap.com Mon Dec 14 12:13: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 1D7F63A6902 for ; Mon, 14 Dec 2009 12:13:34 -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 Kv+La7pUsUWb for ; Mon, 14 Dec 2009 12:13:31 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 520D63A68C4 for ; Mon, 14 Dec 2009 12:13:30 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBEKDDU6002170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 21:13:13 +0100 (MET) From: Martin Rex Message-Id: <200912142013.nBEKDB0C018687@fs4113.wdf.sap.corp> To: bmoeller@acm.org (Bodo Moeller) Date: Mon, 14 Dec 2009 21:13:11 +0100 (MET) In-Reply-To: from "Bodo Moeller" at Dec 3, 9 01:01: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, james@manger.com.au Subject: Re: [TLS] matching identity, by default 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, 14 Dec 2009 20:13:34 -0000 Bodo Moeller wrote: > > My point wasn't actually that I expect the peer's "identity" to change > -- I expect that the peer's *identification information* may change in > renegotiation handshakes, while each party should still be able to > rely that it's continuing to talk to the *same* peer it has > authenticated in the preceding handshake. OpenSSL actually has been offering a "lockdown established identity" for the client (cert) during TLS renegotiation (I'm unsure whether this applies also to cached sessions, but I believe so) for probably 10 years at least. It is the verify option SSL_VERIFY_CLIENT_ONCE, which will cause an OpenSSL server to _not_ send a CertificateRequest message in a TLS renegotiation handshake if the server has already obtained a client certificate in a previous handshake. -Martin From yngve@opera.com Mon Dec 14 12: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 A34763A68C4 for ; Mon, 14 Dec 2009 12:16:15 -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 aNJj+w+y9M-g for ; Mon, 14 Dec 2009 12:16:14 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 210ED3A691F for ; Mon, 14 Dec 2009 12:15:58 -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 nBEKDYoZ009108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Dec 2009 20:13:40 GMT Date: Mon, 14 Dec 2009 21:15:38 +0100 To: 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: <200912141911.nBEJBmMr014961@fs4113.wdf.sap.corp> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200912141911.nBEJBmMr014961@fs4113.wdf.sap.corp> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in 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, 14 Dec 2009 20:16:15 -0000 On Mon, 14 Dec 2009 20:11:48 +0100, Martin Rex wrote: > Yngve Nysaeter Pettersen wrote: >> >> I am talking about a client, as all current Browser clients, that have >> to >> allow the use of non-extension handshakes because of interoperability >> reasons. >> >> In that *particular* situation, when it does not know that it is about >> to >> talk to an RI patched server. Upon discovering that it is indeed RI >> patched, based on my suggestions for requireiement the client knows two >> additional things: 1) It can use the RI extension with this server, and >> 2) >> it have to make sure that it was not forced to use an older SSL/TLS >> version than it supports. Therefore it should tear down the connection >> and >> re-establish it, in Opera's case signalling support for TLS 1.2 and >> using >> the RI extension, and (again assuming my proposal is accepted) the >> server >> will accept the hello, respond with a RI extension and its highest >> supported version if it is lower than Opera's, and Opera's if the server >> supports a newer version. If the handshake fails in this situation >> somebody is trying to perform a version rollback attack against the >> client. > > That is _not_ a version rollback attack (on the TLS protocol version), > but instead a downgrade attack on your fallback logic. It is unrelated > to the TLS renegotiation vulnerability. IMO there is no real difference, since the fallback logic was added to handle broken server implementations. >> I am not talking applevel, I am saying that the SSL/TLS implementation >> must restart the connection. > > Going through a handshake failure would be a fairly broken solution > an can not possibly work at the TLS protocol level. > > What you could use is either the MS SGC logic (which internally > restarts the handshake mid-way), or successfully complete the > handshake and renegotiate immediately after with better features. Not a good idea since it requires that the server knows about it. MS was in charge of both sides for SGC. > Any form of handshake failure, reconnect and new handshake ill > require apps-level support for this. Quite a number of TLS > implementations > do not include transport, and even those that include transport can > usually not perform a re-connect all by themselves. (How many > TLS implementations perform things like a HTTP CONNECT proxy traversal > all by themselves, instead of getting an established network connection > handle where they should start a TLS handshake? The clients that have fallback is already able to handle that. As I mentioned futher down, clients that doesn't just have to specify the highest version they support. >> The case where that may cause problems, is >> for upgradeable protocols features like SMTP STARTTLS, and I assume that >> all those clients either already have a fallback mechanism that requires >> restart and have an application layer that can handle that, or they >> signal >> their highest version and uses extension (if they support it) all the >> time, and expect the server to tolerate it. > > I assume that few, if any, have a fallback retry logic. > > They usually may have a possibility to select a protocol version upfront > (SSLv2, SSLv3, TLSv1), and depending on their age (or more precisely > the age of their TLS implementation), might not be using TLS > extensions so far, even when TLSv1 is selected. Well, I am talking about clients implementations supporting TLS 1.1 or TLS 1.2, with Extensions used for those protocol modes. > The "canonical" clients would be "curl" and WinHTTP. Which one of > these currently has a fallback retry logic? No idea, but curl probably sends the highest supported version, and fails if the server refuses to talk. The Windows HTTP stack probably perform a fallback if necessary, handled by the Windows SSL stack. >> If it is desirable to avoid restarts, the simple way to handle that is >> to >> signal highest version and the extension, and require the server to >> handle >> it. > > You can implement whatever fancy fallback logic you like in your > TLS clients. Just make sure you do not end up in a deadly embace. > (that might be particularly bad for mobile customers of the Opera > browser which pay-per-volume). I want to get rid of the fallback, or even the upgrade (fallup?) mentioned above, and in the case of the upgrade it is a temporary measure until the client enters strict mode. >> >> I therefore think it is unlikely that a general purpose client will >> >> encounter a server that does not understand the RI extension, and >> IMO we >> >> might just as well make it a requirement that all servers MUST >> >> understand >> >> the extension. But I can live with the possibility that the MCSV >> have to >> >> be sent in all initial handshakes, as long as all servers MUST at >> least >> >> be >> >> TLS extension tolerant. >> > >> > To get rid of complexity, the empty TLS extension RI for ClientHello >> > should be completely removed from the specification (i.e. MUST be >> ignored >> > by servers if present). >> >> I disagree. The empty RI should be the default, and the MCSV only used >> when a *lenient* client connects to an *unknown* server, optionally >> using >> a fallback to a configuration that does not support extensions. > > That would be adding unnecessary complexity without value. > > Either you do not need MCSV, then you should get rid of that, > or you need MCSV, then you should get rid of empty TLS extension RI > _in_the_ClientHello_. Having both is a completely unnecessary > complexity, requires extra code, extra testing, will lead to extra > bugs and amounts to pure waste. In a lenient mode MCSV seems necessary, but not after strict mode has been entered, assuming TLS Extension tolerance is a requirement. >> >> My position is that the time for changeover before clients turn strict >> should be no more than 12 months, preferably less. > > Btw. I still haven't understood what the "lenient client" and > "lenient servers" are that some people have been refering to. "Lenient client" means that it is willing to talk to an unpatched server, "strict client" is one that throws a fatal error when not receiving the RI extension from the server. My position is that lenient clients should only be so for a specified number of months, after which they become strict. >> > *I* would not refer to the fallback re-try logic in your Browser as >> > a security hole. It definitely does not need to be one, and it's >> > completely up to your implementation to ensure that. >> >> It is *impossible* for such fallback code to determine if the server is >> broken or there is an attack going. To interoperate we have had to open >> a >> security hole, and it is time and more than time to close it >> permanently. > > If you think it is a security hole, then you are free to disable it > _in_your_implementation_. As I've pointed out, repeatedly, the fallback is there because it is necessary in order to connect to major sites using broken server, such as the bank I mentioned a couple of weeks ago. > Personally, I do not think there currently is a known serious > security problem with an extension-less SSLv3 ClientHello. No, there isn't. Right now, that is, as far as we know. What about in a year or three? (Keep in mind that it took a while for the renego issue, or the 2008 DNS issue to become publicly known) >> > Your idea is an expensive mitigation strategy at best >> >> Expensive? Making sure an if-then-else clause and a variable check is >> correct should not be expensive, nor should fixing it be expensive >> either. >> The servers have to be fixed anyway. > > It is also expensive in terms of testing an extra code path, Only if the server was non-compliant *already*, if it is compliant, no need to do anything. If there is a problem, better fix it now when they have to ship an update anyway, or they will have to rush out a fix when the clients get tired of waiting for the last few servers and just disable the fallback. That is likely to be much more expensive. >> There is already a way for that signal: The client signal its highest >> version, the server selects the lowest of its version and the client's >> stated version, and in RSA also double check this with the version >> number >> in the RSA Premaster Secret. > > No, there is not. You mentioned it yourself, that in your fallback you > will send a low protocol version number in ClientHello.client_version > (maybe even { 0x03, 0x00 }, which is why you came up with the fancy > ideas to close the connection and retry -- simply because you do > _not_ know the highest protocol version that the server actually > supports. Only because we have all had to add a fallback in order to handle bad servers, which implicitly broke that protection. If clients start using the correct version (and ignore the howls from users and web site owners) that system will be back in function again automatically. No need to do anything else, except requiring servers to play along, which is why I would like those requirements about TLS Extension tolerance and version tolerance in the RI specification; and much of the version tolerance part is really just a reminder about what all the SSL and TLS specifications already say. >> What I am saying is that it is conceivable that we could have a break >> in, >> for example, SSL v3 that makes a live attack on the protocol feasible, >> but >> only if it can trick the client and server to negotiate a SSL v3.0 >> connection, and today that is *trivial*; all major clients do it >> *automatically*! Once that news reach the community there will be a mad >> scramble to disable SSLv3 in servers and clients, and to disable the >> fallback. > > I'm sorry, I don't see that problem. The Browsers I have, even those > as old as MSIE 6 on Windows XP let me disable SSLv3 support if I want to. > Maybe there is a problem in your _implementation_ ? No, there is no such problem in my implementation, in fact, with respect to SSL v3 I can turn it off in all deployed Opera 10.00+ installations within 7 (seven) days. The same thing apply to MD5 and SHA-1 in certificates, and will soon apply to the unpatched renego servers and the TLS fallback, and as soon as I get around to checking the state-engine (or remove the ladder climber aka the fallback), TLS 1.0 and TLS 1.1. The real problem is deploying such manual workarounds. Just how many users do you think disable Javascript or plugins because of the latest issue in their browser? No need to answer. Very few. -- 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 stpeter@stpeter.im Mon Dec 14 12:36: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 BED3C3A692A; Mon, 14 Dec 2009 12:36:55 -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 sP0UbcOvnuN8; Mon, 14 Dec 2009 12:36:54 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A371B3A63EC; Mon, 14 Dec 2009 12:36:54 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BB53140337; Mon, 14 Dec 2009 13:36:40 -0700 (MST) Message-ID: <4B26A1D7.90702@stpeter.im> Date: Mon, 14 Dec 2009 13:36:39 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <20091214191959.427A53A6A27@core3.amsl.com> <20091214194431.GO1516@Sun.COM> In-Reply-To: <20091214194431.GO1516@Sun.COM> 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="------------ms010807000908090702050002" Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 14 Dec 2009 20:36:55 -0000 This is a cryptographically signed message in MIME format. --------------ms010807000908090702050002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/14/09 12:44 PM, Nicolas Williams wrote: > On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote: >> As a protocol climbs the IETF standards-track maturity ladder, we >> sometimes drop features. I would rather see renegotiation dropped >> from TLS than see this complexity added to TLS protocol. > > I would like to agree. There's no real-world need to re-negotiate for > re-keying nowadays: with the advent of 128-bit block block ciphers > there's little need. > > But re-negotiation remains useful for other purposes. Probably the most > obvious ones are optional authentication and privacy protection for > client credentials. I'm not sure those are sufficiently useful or > important to warrant keeping the feature, but if not then dropping the > feature does seem like a better option than fixing it. Even if the WG decided not to drop renegotiation, I do think it would be helpful to document why the feature is important and useful in the first place. As far as I can see, both draft-ietf-tls-renegotiation and draft-mrex-tls-secure-renegotiation assume that renegotiation is a good thing, and RFC 5246 contains only this assertion: While renegotiation is an optional feature, supporting it is highly recommended. A more detailed justification might be helpful. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms010807000908090702050002 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 hvcNAQkFMQ8XDTA5MTIxNDIwMzYzOVowIwYJKoZIhvcNAQkEMRYEFFl64R6zkmLDVYp4gESf YwuZRxEyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAk8Q+HZiDWxGvASTYyMW/zNVi1iKNfv93PgU7fIYA r/4uwj08Rj6bUBu7dFNm+C5Tba/R0lTm85JdX0dbLyqMA5rNX69U4c9i4lxnhcXwhknaK4d3 GrF1ZAes6yTSuPde+wyX+eByhBf2nvOXSLnRdPSVJvSCNif1oG9j0L7hURIMm1PgsiC1zvLE HY3GXffCK8+iQHVxxgR+hitCjae5qWmOoxwcHoKyJ7Wbg5nAfpFZfsr0dwascfANOr6KZziA 4lL4NNkFbCBvMcXn+xlKkZRRVBj36xNHEXvyxgzDYheShKJwbutGVQmmCxLmpRl3baaOap9J msO+uBPu/u1MwgAAAAAAAA== --------------ms010807000908090702050002-- From ynir@checkpoint.com Mon Dec 14 12:38: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 DD6D03A68A7 for ; Mon, 14 Dec 2009 12:38:30 -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 hUF9t6bSdXHP for ; Mon, 14 Dec 2009 12:38:29 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E54703A63EC for ; Mon, 14 Dec 2009 12:38:28 -0800 (PST) X-CheckPoint: {4B26A173-10003-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1AA8A29C004; Mon, 14 Dec 2009 22:38:15 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 03CDE29C002; Mon, 14 Dec 2009 22:38:15 +0200 (IST) X-CheckPoint: {4B26A172-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBEKcET7018424; Mon, 14 Dec 2009 22:38:14 +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, 14 Dec 2009 22:38:25 +0200 From: Yoav Nir To: Sebastian Gajek , "tls@ietf.org" Date: Mon, 14 Dec 2009 22:35:54 +0200 Thread-Topic: Closing some open comments on draft-ietf-tls-renegotiation Thread-Index: Acp80/0d4zm97OCPEkiT1QBeYxZnuQAKQs+1 Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.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 Subject: Re: [TLS] Closing some open comments on 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, 14 Dec 2009 20:38:31 -0000 It would be easy to require this, but it's not compliant with the current s= pec. The current spec says that the finished value depends on all the bytes= starting with the first byte of the ClientHello. We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but add= ing the previous finished message is a change to the spec, one that require= s some sort of signaling, either with a fake cipher suite or with an extens= ion. ________________________________________ From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Sebastian Ga= jek [gajek@post.tau.ac.il] Sent: Monday, December 14, 2009 17:42 To: tls@ietf.org Subject: [TLS] Closing some open comments on draft-ietf-tls-renegotiation Hi there, sorry for putting another mail into the long list of TLS renegotiation mails. I skimmed the TLS-renegotiation draft. Surely, a countermeasure is t= o cryptographically link the TLS sessions. There are different approaches to achieve this goal. I was wondering why you introduce a new cipher suite. Wouldn't it be easier to require that finished values are a function of all values received so far (incl. previous TLS sessions or at least their finished values.) This countermeasure is simple, complies with the present TLS spec and could result in faster adaption. Is there a technicality I am not aware? Thx for any feedback. From DPKemp@missi.ncsc.mil Mon Dec 14 13:01: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 75BA93A68C7; Mon, 14 Dec 2009 13:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=1.601, 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 yoIEaNwmDTpc; Mon, 14 Dec 2009 13:01:44 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 8DFC63A63EC; Mon, 14 Dec 2009 13:01:44 -0800 (PST) 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, 14 Dec 2009 16:01:06 -0500 Message-ID: <200912142101.nBEL1Vle026550@stingray.missi.ncsc.mil> In-Reply-To: <20091214191959.427A53A6A27@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation Thread-Index: Acp88pVXS8ladKwGSVWs8F1ytseEeAAAyHZw References: <20091214191959.427A53A6A27@core3.amsl.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 14 Dec 2009 21:01:52.0500 (UTC) FILETIME=[A9292B40:01CA7D00] Cc: tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 14 Dec 2009 21:01:45 -0000 One use of renegotiation is to obscure endpoint identities, as supported in IPsec by protecting IKE_AUTH messages under keys established in an IKE_SA_INIT exchange. If identity protection were required in TLS (I'm not claiming that it is) and renegotiation is not allowed, the obvious choice is to tunnel authenticated TLS inside an anonymous TLS session. Are there alternatives to renegotiation or tunneling? The overhead of maintaining two record layers over the lifetime of a connection seems high, and I'm not aware of a standard mechanism for establishing a tunnel in the first place, or for tearing down the outer layer after the inner handshake has completed. Could a special-purpose identity protection handshake be defined in a manner that is both simpler and safer than full renegotiation? Just want to fully consider the consequences before discarding a feature. In practice it doesn't matter, since the market will decide if a Draft Standard TLS with patched renegotiation will still be supported after Full Standard TLS is defined. Dave -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, December 14, 2009 2:20 PM To: iesg@ietf.org Cc: tls@ietf.org Subject: [TLS] COMMENT: draft-ietf-tls-renegotiation Comment: As a protocol climbs the IETF standards-track maturity ladder, we sometimes drop features. I would rather see renegotiation dropped from TLS than see this complexity added to TLS protocol. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From pgut001@wintermute01.cs.auckland.ac.nz Mon Dec 14 13:14: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 C31973A6887; Mon, 14 Dec 2009 13:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.208 X-Spam-Level: X-Spam-Status: No, score=-5.208 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_00=-2.599, 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 t6+CDOx5Fe04; Mon, 14 Dec 2009 13:14:54 -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 DD9083A680D; Mon, 14 Dec 2009 13:14:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 877B61A951; Tue, 15 Dec 2009 10: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 OD13lZL6pr5y; Tue, 15 Dec 2009 10:14: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 613731A8DE; Tue, 15 Dec 2009 10:14:31 +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 1NKIFT-0006rf-Im; Tue, 15 Dec 2009 10:14:31 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1NKIFT-0007qn-OR; Tue, 15 Dec 2009 10:14:31 +1300 From: Peter Gutmann To: housley@vigilsec.com, Nicolas.Williams@sun.com In-Reply-To: <20091214194431.GO1516@Sun.COM> Message-Id: Sender: pgut001 Date: Tue, 15 Dec 2009 10:14:31 +1300 Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 14 Dec 2009 21:14:54 -0000 Nicolas Williams writes: >On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote: >> As a protocol climbs the IETF standards-track maturity ladder, we >> sometimes drop features. I would rather see renegotiation dropped >> from TLS than see this complexity added to TLS protocol. > >I would like to agree. There's no real-world need to re-negotiate for >re-keying nowadays: with the advent of 128-bit block block ciphers >there's little need. +1. I've never supported renegotiation in my code because I saw it as mostly a source of trouble due to the complexity involved in implementing it. In addition: >But re-negotiation remains useful for other purposes. Probably the most >obvious ones are optional authentication and privacy protection for >client credentials. I'm not sure those are sufficiently useful or >important to warrant keeping the feature, but if not then dropping the >feature does seem like a better option than fixing it. ... in 10+ years of providing SSL/TLS support I've never had anyone request it, or ask about privacy protection for client credentials. Admittedly there could have been millions of potential users who silently turned away because this facility was missing, but somehow I doubt it. Peter. From nelson@bolyard.me Mon Dec 14 13:20: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 274053A68AF for ; Mon, 14 Dec 2009 13:20:17 -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 HV1GZCzttuXA for ; Mon, 14 Dec 2009 13:20:16 -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 2B15C3A68C7 for ; Mon, 14 Dec 2009 13:20:16 -0800 (PST) Received: (qmail 8404 invoked from network); 14 Dec 2009 21:20:02 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 14 Dec 2009 21:20:02 -0000 Message-ID: <4B26AB9B.9020404@bolyard.me> Date: Mon, 14 Dec 2009 13:18:19 -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: <200912140211.nBE2B2rp012757@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in servers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2009 21:20:17 -0000 On 2009-12-14 03:16 PST, Yngve N. Pettersen wrote: > The main point of my entire suggestion is that since ALL servers and > clients have to be patched anyway, that the RI proposal already makes (at > least) TLS tolerance a requirement, and that many servers are implemented > in a fashion that forces all general clients to behave in an unsecure > fashion (automatic version rollback) it would also IMO be a very good idea > to close that security hole at the same time as we close the current hole, > and make it very clear that the version negotiation problem will no longer > be tolerated by RI capable clients. > > This is an opportunity to close *two* security holes at the same time, and > I think we should take it. > > If we don't take this opportunity, we may well have to repeat the "patch > all servers" routine again in, at most, a few years. I think that is an > expensive way to save a few hours of checking that a few lines of code are > actually doing what they should have been doing the past 15 years, and if > necessary fix them. I fully agree with all these points. TLS was designed to detect and defeat version roll-back attacks. Clients that do "TLS intolerant fall-back" due to servers that do not properly negotiate version numbers and do not tolerate unknown extensions are clients that are completely vulnerable to version roll-back attacks. I fully endorse your proposal, but I only represent a TLS library used by a browser, not a browser. I hope that other browsers (in addition to Opera) will also endorse your proposal very soon. From mrex@sap.com Mon Dec 14 15: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 7A33F3A6868 for ; Mon, 14 Dec 2009 15:29:06 -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 b4iDOYYAdeVw for ; Mon, 14 Dec 2009 15:29:05 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F1B423A63EC for ; Mon, 14 Dec 2009 15:29:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBENSo3q016415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Dec 2009 00:28:50 +0100 (MET) From: Martin Rex Message-Id: <200912142328.nBENSnYx000534@fs4113.wdf.sap.corp> To: yngve@opera.com Date: Tue, 15 Dec 2009 00:28:49 +0100 (MET) In-Reply-To: from "Yngve Nysaeter Pettersen" at Dec 14, 9 09:15:38 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] RI, TLS Extension tolerance and version tolerance 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: Mon, 14 Dec 2009 23:29:06 -0000 Yngve Nysaeter Pettersen wrote: > > > I assume that few, if any, have a fallback retry logic. > > > > They usually may have a possibility to select a protocol version upfront > > (SSLv2, SSLv3, TLSv1), and depending on their age (or more precisely > > the age of their TLS implementation), might not be using TLS > > extensions so far, even when TLSv1 is selected. > > Well, I am talking about clients implementations supporting TLS 1.1 or TLS > 1.2, with Extensions used for those protocol modes. I just checked the implementations that I have around here. * MSIE7 on Windows 2008: offer TLS extensions, but Internet Options says about available protocols: SSLv2, SSLv3, TLSv1.0 * MSIE7 on WinXPpro64bit: no TLS extension, Internet Options shows available protocols: SSLv2, SSLv3, TLSv1.0 * Firefox 3.5.5: offers TLS extensions. Protocol versions shown in Options/Advanced-Section/Encryption Tab: SSLv3, TLSv1.0 * OpenSSL-0.9.8l: offers TLS extensions, available protocol versions appear to be SSLv2, SSLv3, TLSv1.0 TLSv1.1 or even TLSv1.2 seems to be not exactly common these days. There probably still are a few interop problems around TLSv1.0 {0x03,0x01} but I would not be surprised about interop problems for TLSv1.1 and above. What isn't tested, can not be blindly assumed to work. Waving with a TLSv1.1 or TLSv1.2 spec is not going to impress any of the deployed code, and only marginally impress vendors, I assume. > > >> My position is that the time for changeover before clients turn strict > >> should be no more than 12 months, preferably less. > > > > Btw. I still haven't understood what the "lenient client" and > > "lenient servers" are that some people have been refering to. > > "Lenient client" means that it is willing to talk to an unpatched server, > "strict client" is one that throws a fatal error when not receiving the RI > extension from the server. > > My position is that lenient clients should only be so for a specified > number of months, after which they become strict. I'm confused why you removed the list that I showed here. If you really want to discontinue talking to all SSL/TLS peers that have not been updated, then this is likely to have that Opera version drop out of the client access statistic of a number of websites. Such an action would be significantly more disruptive than suddenly sending TLS extensions on every ClientHello. Personally I think it is a bad idea to alienate your own users with a new version of your software -- or a patch to that effect. Making your users regret the have the software on auto-update is going to hurt everyone. > > > Personally, I do not think there currently is a known serious > > security problem with an extension-less SSLv3 ClientHello. > > No, there isn't. Right now, that is, as far as we know. What about in a > year or three? (Keep in mind that it took a while for the renego issue, or > the 2008 DNS issue to become publicly known) The TLS renegotiation issue went unnoticed for so long because nobody cared to look for it. To me it looks a little weird that so many implementors have missed it entirely. I don't know what you mean by 2008 DNS issue. Is it about the embedded NUL characters in distinguished names? Or the OID integer overflows in attribute OIDs of distinguished names? That is also a mystery to me how so many implementers got this wrong. To me, this suggests that a spec as complex as TLS extension RI and as underspecified as draft-ietf-tls-renegotiation-01 will turn a single common problem into a whole set of new interop problems. > >> Once that news reach the community there will be a mad > >> scramble to disable SSLv3 in servers and clients, and to disable the > >> fallback. > > > > I'm sorry, I don't see that problem. The Browsers I have, even those > > as old as MSIE 6 on Windows XP let me disable SSLv3 support if I want to. > > Maybe there is a problem in your _implementation_ ? > > The real problem is deploying such manual workarounds. Just how many users > do you think disable Javascript or plugins because of the latest issue in > their browser? No need to answer. Very few. A TLS client in form of a web browser that offers active content and Javascript worries about the security of SSLv3 vs TLSv1.x? In this constallation, _my_ empathy level drops to plain zero. There are bugs found in Javascript and other active content on a monthly basis. It can be switched off by users. It won't. And I haven't heard you proposing to disable active content through SmartUpdate (or whatever you call it), although that would probably improve the security on the internet _MUCH_ more than deprecating extension-less SSLv3. -Martin From yngve@opera.com Mon Dec 14 16:58: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 92FE63A687F for ; Mon, 14 Dec 2009 16:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 rdGQ+EG-O3GN for ; Mon, 14 Dec 2009 16:58:01 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 2FE553A687B for ; Mon, 14 Dec 2009 16:58:00 -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 nBF0tcm5018069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Dec 2009 00:55:40 GMT Date: Tue, 15 Dec 2009 01:57:40 +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: <200912142328.nBENSnYx000534@fs4113.wdf.sap.corp> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200912142328.nBENSnYx000534@fs4113.wdf.sap.corp> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2009 00:58:02 -0000 On Tue, 15 Dec 2009 00:28:49 +0100, Martin Rex wrote: > Yngve Nysaeter Pettersen wrote: >> >> > I assume that few, if any, have a fallback retry logic. >> > >> > They usually may have a possibility to select a protocol version >> upfront >> > (SSLv2, SSLv3, TLSv1), and depending on their age (or more precisely >> > the age of their TLS implementation), might not be using TLS >> > extensions so far, even when TLSv1 is selected. >> >> Well, I am talking about clients implementations supporting TLS 1.1 or >> TLS >> 1.2, with Extensions used for those protocol modes. > > I just checked the implementations that I have around here. > > * MSIE7 on Windows 2008: offer TLS extensions, but Internet Options > says about available protocols: SSLv2, SSLv3, TLSv1.0 > > * MSIE7 on WinXPpro64bit: no TLS extension, Internet Options > shows available protocols: SSLv2, SSLv3, TLSv1.0 > > * Firefox 3.5.5: offers TLS extensions. Protocol versions shown > in Options/Advanced-Section/Encryption Tab: SSLv3, TLSv1.0 > > * OpenSSL-0.9.8l: offers TLS extensions, available protocol > versions appear to be SSLv2, SSLv3, TLSv1.0 > > TLSv1.1 or even TLSv1.2 seems to be not exactly common these days. * Opera 10 with TLS 1.2 (and TLS 1.1 since 8.0, enabled since 9.0) * MSIE 8 and IIS on Windows 7, but disabled by default. > There probably still are a few interop problems around TLSv1.0 > {0x03,0x01} > but I would not be surprised about interop problems for TLSv1.1 and > above. > What isn't tested, can not be blindly assumed to work. Waving with > a TLSv1.1 or TLSv1.2 spec is not going to impress any of the deployed > code, and only marginally impress vendors, I assume. I would not wave with the TLS 1.2 spec. I would wave with the last SSL v3 draft and the 10 year old TLS 1.0 spec or whatever is relavnt for that particular server. Both of those says exactly the same as TLS 1.1 and TLS 1.2 about version negotiation and extensions, and how they are to be handled. I'd be waving the TLS 1.2 spec at another TLS 1.2 implementor if there was an interoperability problem between our implementation, or he would be waving it at me; but for an server supporting an older version of the protocol encountering a client supporting a newer version the rules are crystal clear, and have been so for about 13-15 years. It is about time we start enforcing those rules. >> >> My position is that the time for changeover before clients turn >> strict >> >> should be no more than 12 months, preferably less. >> > >> > Btw. I still haven't understood what the "lenient client" and >> > "lenient servers" are that some people have been refering to. >> >> "Lenient client" means that it is willing to talk to an unpatched >> server, >> "strict client" is one that throws a fatal error when not receiving the >> RI >> extension from the server. >> >> My position is that lenient clients should only be so for a specified >> number of months, after which they become strict. > > > I'm confused why you removed the list that I showed here. If you > really want to discontinue talking to all SSL/TLS peers that have not > been updated, then this is likely to have that Opera version drop out > of the client access statistic of a number of websites. > > Such an action would be significantly more disruptive than suddenly > sending TLS extensions on every ClientHello. > > Personally I think it is a bad idea to alienate your own users > with a new version of your software -- or a patch to that effect. > Making your users regret the have the software on auto-update > is going to hurt everyone. What makes you think we would go solo on such an action? What I have stated is my opinion about what should be done and my preferred timeframe, not what has been decided, which is still very much up in the air. I have also stated what preparations I am going to make for the time when such an action can be carried through, whether it is 6 months or 10 years from now. Such an operation would at least have to be coordinated with all the major browser vendors and a date agreed upon. And yous seem to be making the (IMO) mistaken assumption that web site owners will not move to update their servers if/when it becomes an issue. For that matter they are probably already waiting impatiently for renego fixed servers so that they can tell their users that their site is secure. For that matter, I wonder how long before the web sites become strict about the renego issue? >> > Personally, I do not think there currently is a known serious >> > security problem with an extension-less SSLv3 ClientHello. >> >> No, there isn't. Right now, that is, as far as we know. What about in a >> year or three? (Keep in mind that it took a while for the renego issue, >> or >> the 2008 DNS issue to become publicly known) > > > The TLS renegotiation issue went unnoticed for so long because nobody > cared to look for it. To me it looks a little weird that so many > implementors have missed it entirely. My point was about time from discovery to publication. > I don't know what you mean by 2008 DNS issue. Is it about the As in the DNS issue discovered by Kaminsky and revealed summer 2008 that required all DNS servers to be updated. (much like the current renegotiation issue) > embedded NUL characters in distinguished names? Or the OID integer > overflows in attribute OIDs of distinguished names? That is also > a mystery to me how so many implementers got this wrong. Rethorial question mayb, but: Why did the Y2K problem develop? Too many assumtions, maybe? Possibly including assumptions about how it could be fixed properly later, before it became an issue? Some string representations use a length field (like ASN.1), other NUL-termination. When the first was converted to the second, nobody considered the possibility of a NUL in the middle of the string, quite possibly because it was not possible in the format they normally used. In the integer case you have a format that can represent integers of virtually any size; known examples all fit into 32 or (later) 64 bit, which made them easy to handle... Take it from there. > To me, this suggests that a spec as complex as TLS extension RI > and as underspecified as draft-ietf-tls-renegotiation-01 will > turn a single common problem into a whole set of new interop > problems. A reference implementation would help, which was one of my suggestions in the TLS interoperability draft. -- 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 Dec 14 17:22: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 EA9FC3A6782 for ; Mon, 14 Dec 2009 17:22:43 -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 HMYT0RL7K26M for ; Mon, 14 Dec 2009 17:22:43 -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 E99FB3A6817 for ; Mon, 14 Dec 2009 17:22:41 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 44D74A6295 for ; Mon, 14 Dec 2009 20:22: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=VoU1igHHSuL0 FmZeq/Eg4MxpQtY=; b=hGrEnzglzbDkVBfCeH7pRUq+/uW2hnoyox0Ri7lf+XNk fshhgL8zgvOoVJjzLYYoU1cXFsVSaCUamHpru0YDLSTX6DwS2F0oltYvheGvIqUh fSw1SUmF0eSRB01tPEoYpukVmqBmfqhRh5r6xDrnwYYP3Nl5pfYStJ4gKKmlbCY= 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=KED2sv IBNM7ysJPLxejzkVjgAeFYH0ML8u3iV2GWynEC2H1lIIjXgTm3bU01MqT13LHStN Eaz2tN2suC8DvLi+hIdm0w23/2fzCSULiapFIrm7hr4kKjoufk6F/cQdMVdvBzGh V2dasSdlHbJeb7rCix58qZ/DnKXwoDbL/EG0I= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 41AC5A6294 for ; Mon, 14 Dec 2009 20:22: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 A3B6DA6293 for ; Mon, 14 Dec 2009 20:22:27 -0500 (EST) Message-ID: <4B26E53D.6000904@pobox.com> Date: Mon, 14 Dec 2009 17:24:13 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200912142328.nBENSnYx000534@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4F091E70-E918-11DE-B037-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2009 01:22:44 -0000 Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Tue, 15 Dec 2009 00:28:49 +0100, Martin Rex wrote: >> To me, this suggests that a spec as complex as TLS extension RI >> and as underspecified as draft-ietf-tls-renegotiation-01 will >> turn a single common problem into a whole set of new interop >> problems. > > A reference implementation would help, which was one of my suggestions > in the TLS interoperability draft. My server has been updated to speak RI (0xFF01) and MCSV (current value is 0xBFFF): https://www.mikestoolbox.net And I added a feature where if you ask for a particular page it will turn around and act as a client, connect to your IP address on port 443, request "/", and then attempt to renegotiate using RI. Send me a private email for the link. Mike From stefan@aaa-sec.com Mon Dec 14 17:40: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 CF4003A693C for ; Mon, 14 Dec 2009 17:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 rpE6yVDoR6Vu for ; Mon, 14 Dec 2009 17:40:22 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 02E563A691A for ; Mon, 14 Dec 2009 17:40:21 -0800 (PST) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 00900564DAA for ; Tue, 15 Dec 2009 02:37:12 +0100 (CET) Received: (qmail 75689 invoked from network); 15 Dec 2009 01:37: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 s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Dec 2009 01:37:02 -0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 15 Dec 2009 02:37:01 +0100 From: Stefan Santesson To: Nicolas Williams , Russ Housley Message-ID: Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation Thread-Index: Acp9Jxj+qDnwvxw+UUiF+OWqDlgxpA== In-Reply-To: <20091214194431.GO1516@Sun.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 01:40:22 -0000 The fact that it is used for legitimate purposes makes me worried about the consequences of just abandoning it without fixing it. Perhaps a middle way is to not fix it and not to remove it, but simply clarify it's security properties. I'm still not convinced you can't use unpatched renegotiation securely if applications simply don't accept messages sent before completed renegotiation as being delivered under the context of the renegotiated connection. Other's have suggested the same. /Stefan On 09-12-14 8:44 PM, "Nicolas Williams" wrote: > On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote: >> As a protocol climbs the IETF standards-track maturity ladder, we >> sometimes drop features. I would rather see renegotiation dropped >> from TLS than see this complexity added to TLS protocol. > > I would like to agree. There's no real-world need to re-negotiate for > re-keying nowadays: with the advent of 128-bit block block ciphers > there's little need. > > But re-negotiation remains useful for other purposes. Probably the most > obvious ones are optional authentication and privacy protection for > client credentials. I'm not sure those are sufficiently useful or > important to warrant keeping the feature, but if not then dropping the > feature does seem like a better option than fixing it. > > Nico From djhopwood@googlemail.com Mon Dec 14 18:46: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 9D7FB3A6897 for ; Mon, 14 Dec 2009 18:46: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=[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 TCNvaOjsg4G3 for ; Mon, 14 Dec 2009 18:46:26 -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 589F23A67EF for ; Mon, 14 Dec 2009 18:46:26 -0800 (PST) Received: by ewy6 with SMTP id 6so2614972ewy.29 for ; Mon, 14 Dec 2009 18:46: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=qwo8RHwQ4/yVL+F8yE4dlfoPlIKrk4drEbPJc6V1HV8=; b=E7CPRhDQMcIhSFFDQ9ZrbfRFMxEyZ3h/zT9QQPDMwhlru6L9cy+7+83rQAzYVgQ9Fv /2CrtuUPePKeHgsll3apFuLpwl/49Zclqtx/QeZtmgaDp/dO9fZLicuFhsBZJAszZ/eC gWxgkEEeUGN6UjkS8tPFoSN8kW3Yq7/uTlmMw= 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=p935kjWa51UnoYjEKIksl/XIRzus+ZcnGCiqqdlRuE3x6/lAW6dWTJYk7QEDKgYCeX WZti+rKnjdYoRTFRVpFEqa3vqSCpMkMWt2ZxDoi4kAUcp2QSoOLhlvwedI3+uZm6K0bw wVh7DlmJbiDLDx9hyGsPnOoccpl/nObzwLITU= Received: by 10.213.50.139 with SMTP id z11mr4520928ebf.13.1260845169141; Mon, 14 Dec 2009 18:46:09 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 15sm3418433ewy.4.2009.12.14.18.46.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 18:46:08 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B26F86D.4020601@jacaranda.org> Date: Tue, 15 Dec 2009 02:46: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: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5DFF283758364BB18044D342" Subject: Re: [TLS] Closing some open comments on 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, 15 Dec 2009 02:46:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5DFF283758364BB18044D342 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > It would be easy to require this, but it's not compliant with the curre= nt > spec. The current spec says that the finished value depends on all the > bytes starting with the first byte of the ClientHello. >=20 > We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but= > adding the previous finished message is a change to the spec, one that > requires some sort of signaling, either with a fake cipher suite or wit= h > an extension. No, this is a misunderstanding; changing how the Finished message is computed *for renegotiations* does not necessarily require signalling. Changing the way that the Finished message is computed *only* for renegotiations, would affect interoperability only when there is a renegotiation where one peer is unpatched and the other is patched. Under that condition, being interoperable would allow an attack. (Some have argued for allowing patched clients and servers to favour interoperability over security in this case. I don't agree that that is desirable.) Furthermore, changing the Finished message only for renegotiations is sufficient to prevent attacks provided that the renegotiating peer has been updated. By itself, however, that would not allow clients to detect non-patched servers. It is likely, and desirable, that some clients will adopt a "strict" policy in which they fail an *initial* connection to a non-patch= ed server. Technically, only the server->client signal is directly necessary= for this. The client->server signal is needed to allow the server->client= signal to be sent without the possibility of breaking unpatched clients. (The client->server signal also allows servers to reject initial connections from unpatched clients. However, it's unlikely in practice that servers will follow that policy, and it's not necessary to prevent the most serious variant of the attack.) --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig5DFF283758364BB18044D342 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/ iF4EAREIAAYFAksm+HcACgkQWUc8YzyzqAf4+QD/VekN/wwfwdfRIvU9D2k/+hRU 3xacCiUv7lo83iCWpZkA/iz4Q8n7mBCXSWjkO6rXgmeZba7F53cJZOK+BAio1mRL =d8To -----END PGP SIGNATURE----- --------------enig5DFF283758364BB18044D342-- From djhopwood@googlemail.com Mon Dec 14 19:22: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 B1F183A6856 for ; Mon, 14 Dec 2009 19:22: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 65KEp8h3Qsv3 for ; Mon, 14 Dec 2009 19:22: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 14C503A67AE for ; Mon, 14 Dec 2009 19:22:23 -0800 (PST) Received: by ewy6 with SMTP id 6so2635124ewy.29 for ; Mon, 14 Dec 2009 19:22: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=+f0np+JM+555kUqKh0MI9UulE+wZQkyDUZVk3kZTzxo=; b=mTxDv+RfoXdFtpuG7vrg+ehQ8akVAR2x29m24uUV6kekLwFvSn+PDJr36cjLDn3lQF Lr4V59dm/CEids/IHTRDh6mPDIgcu9ldDPlulhgdSt6WVGhC2ix0KhL9bvYsOhddIUI6 9bYoUe9Mt2d0QsOF4XTH26n8XbFiBkEvhGU5U= 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=vPIQqcnYrLJA0nAyhelW14DJeFmALyG8Xv4+uOyHqvh4fWM5FkWglrHM8T/Q4N9mp+ fbjZAD272UYkyqbj8X9wXQDx8Y9/Ueub4CDxfRBEf6jqfV3lMbzA7qE2/XmgwIpvqlA7 BVYO3QzbcyO5wc7ZQs25negpP2zzS5IOUibhM= Received: by 10.213.68.143 with SMTP id v15mr1003763ebi.45.1260847326603; Mon, 14 Dec 2009 19:22:06 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 15sm3437071ewy.0.2009.12.14.19.22.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 19:22:05 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2700DD.5000909@jacaranda.org> Date: Tue, 15 Dec 2009 03:22: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: <200912141540.nBEFe3km002000@fs4113.wdf.sap.corp> In-Reply-To: <200912141540.nBEFe3km002000@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9005FBC746510BFAC5D1DAE6" Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2009 03:22:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9005FBC746510BFAC5D1DAE6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Yngve N. Pettersen wrote: >> A client that does a MCSV-only is almost certainly indicating a versio= n =20 >> less than its highest supported version, and is either doing that beca= use =20 >> it has been forced to fall back to an extensionless Hello (by intolera= nce, =20 >> which rules out an RI capable server, based on my requirements, or by = an =20 >> attacker), or because the client is climbing the version ladder (like = =20 >> Opera), in which case it should try a higher version immediately, anyw= ay. >> >> In combination with my suggestion of directly stating requirements on = RI =20 >> capabable clients and servers about which SSL/TLS version is to be sen= t in =20 >> Client Hellos and serverside version tolerance, the MCSV-only handshak= e =20 >> can be used to detect a version rollback attack and counter it by =20 >> immediately starting to use a Client hello that states highest version= =2E > > This sound somewhat inconclusive to me. If it is possible to force > a client to perform a re-connect fallback, then we can not provide any > protection against this at the TLS protocol level. That is not correct. There are two cases, strict clients (that want to connect only to patched servers), and lenient clients. For a strict client, the requirement that patched servers be both version-tolerant and extension-tolerant allows the client to completely abandon any fallbacks. This is an unqualified Good Thing. For a lenient client, the MCSV tells the server that the client is patched. Then, - if the server is also patched, it sends back the extension in the ServerHello. An attacker can replace this message, but if it does then the Finished verification will fail (provided that part of the protocol remains sound). If the client receives this message, then it knows that it is safe to reconnect without any fallbacks, and without risking any interoperability problem. - if the server is not patched, then we're no worse off than before. In other words, even for lenient clients, this scheme protects against rollback attacks when the server is patched. Whether it is sufficient to prevent a particular future weakness found in TLS will depend on what part of the protocol the weakness occurs in. If it allows the attacker to replace handshake messages, then it won't be prevented, but if it is any other kind of attack, and is dependent on the TLS version, then the attacker will not be able to force a version rollback between a client and server that have both been patched against the renegotiation flaw. [...] > Since we are, in fact, suggesting SSLv3 servers to add the renegotiatio= n > protection patch as well, it would be a flawed assumption that a > server would select newer protocol features if the client had simply > sent a more feature-rich ClientHello. If the server only supports SSLv3, then no rollback attack is possible --= the negotiated version will be SSLv3 and that's the best we can do. > In probabilistic terms, it > might, but since you are talking about a client that will use a > feature-rich ClientHello as default and what you described would only > apply to the fallback scenario, then most of the time this will be > simply an old server. I don't see your point. The goal is that the negotiated version is the maximum that both the client and server can support. The problem is that with fallbacks, that goal isn't necessarily achieved. With Yngve's suggestion, it will be achieved between updated clients and servers. >> I therefore think it is unlikely that a general purpose client will =20 >> encounter a server that does not understand the RI extension, and IMO = we =20 >> might just as well make it a requirement that all servers MUST underst= and =20 >> the extension. But I can live with the possibility that the MCSV have = to =20 >> be sent in all initial handshakes, as long as all servers MUST at leas= t be =20 >> TLS extension tolerant. >=20 > To get rid of complexity, the empty TLS extension RI for ClientHello > should be completely removed from the specification (i.e. MUST be ignor= ed > by servers if present). I agree, but that's completely independent of Yngve's proposal. > Implementation-wise it will be even simpler and more robust, > if MCSV is sent on every renegotiation handshake as well > (i.e. unconditionally included in all ClientHellos), even when > there is an accompanying TLS extension RI with Client.Finished.verify_d= ata. >=20 > This will facilitate code that allows backwards interoperable > renegotiation (server-side). "Backward-interoperable renegotiation" is an insecure distraction. I don't value this as a feature of any solution; actually I think it's a misfeature. However, it is not incompatible with preventing version rollbacks between updated clients and servers. >> This is an opportunity to close *two* security holes at the same time,= and =20 >> I think we should take it. >=20 > *I* would not refer to the fallback re-try logic in your Browser as > a security hole. It definitely does not need to be one, and it's > completely up to your implementation to ensure that. As typically implemented, it is a security hole waiting to happen. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig9005FBC746510BFAC5D1DAE6 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/ iF4EAREIAAYFAksnAOQACgkQWUc8YzyzqAfq0QD/Rw8uMgpXZy2JqJsmRFAZXzc7 dRaPhH/Q6Ma6P40GM0sA/3e90L1iMOg5iqlVKVYtzHVXnj6Zw4MpWiVWtlE/M/PX =J5yw -----END PGP SIGNATURE----- --------------enig9005FBC746510BFAC5D1DAE6-- From djhopwood@googlemail.com Mon Dec 14 19:28: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 443463A697B for ; Mon, 14 Dec 2009 19:28: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 jMTBmQcHYFV6 for ; Mon, 14 Dec 2009 19:28:52 -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 292263A6924 for ; Mon, 14 Dec 2009 19:28:52 -0800 (PST) Received: by ewy6 with SMTP id 6so2638575ewy.29 for ; Mon, 14 Dec 2009 19:28: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=Tmj3ujbC8Jq0oYid7pZOgbDontAMj9bIGEZitiPX6jg=; b=TkSPX3xNzAAxR2/5pGU7DsX/VdQcgo8KVRlVY8sdXR7B657tkvIWoUYPFtCoDL9Apb Tdt7tbou+0KTtSCw4BlD25iQXugclOiOVBHRvXouPwZxhMn9IAL6gX6ncQBzHFBa/vj+ 4zhHHQjvZu5OhRLxsb/c4ROS8cxltcPnHHF/0= 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=aEScaA6QvzHKk7bYDnrnWpB0dlY6ngIhFVzjHp7kdpwQrVxtsQ1hVcDxxP7Tke7oeL VXnM95jKU0H5W2YHQ1mm0+JruK11U6R8pJqwKN+2pQb3smwt4u9Psw7aTZN7IyvOypBF Rg7SV0DHTozFfgheWbqrDbFgIz1H7mwSdmjh4= Received: by 10.213.100.138 with SMTP id y10mr505980ebn.96.1260847715332; Mon, 14 Dec 2009 19:28:35 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 16sm3436158ewy.6.2009.12.14.19.28.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 19:28:34 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B270269.9040909@jacaranda.org> Date: Tue, 15 Dec 2009 03:28: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: <200912141540.nBEFe3km002000@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3810919FB8D5B12F70B158D3" Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2009 03:28:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3810919FB8D5B12F70B158D3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yngve Nysaeter Pettersen wrote: > If the server does not support renegotiation then it might not support > the extension, but my proposal is that it MUST be TLS Extension > *tolerant*. I am however suggestion, optionally, that supporting the > extension should be a MUST in patched servers. It has to be a MUST. Otherwise, - strict clients will unnecessarily abort the handshake when they don't see the extension. - lenient clients won't know to reconnect, so rollback attacks are not necessarily prevented. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig3810919FB8D5B12F70B158D3 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/ iF4EAREIAAYFAksnAmkACgkQWUc8YzyzqAcwgQD9F2Lml74ICsMzq54Z96gYD7yH eUZZYFwAZxeI9ruOHAAA/A9OddFlBiRc/vXcbOT3Nd6/z0lY8OpMjUVqQ8KJEGoe =xb8/ -----END PGP SIGNATURE----- --------------enig3810919FB8D5B12F70B158D3-- From djhopwood@googlemail.com Mon Dec 14 19:46: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 850763A6870 for ; Mon, 14 Dec 2009 19:46: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 mGAwoP3j99x4 for ; Mon, 14 Dec 2009 19:46:21 -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 1B0C83A68DA for ; Mon, 14 Dec 2009 19:46:20 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1006576eyd.51 for ; Mon, 14 Dec 2009 19:46: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=+sqx0qtGLGuYK59z5KRwPXlNrrLxj1FDUDmkrR7BoUc=; b=MsUNMiTI2PvWDC1yiDH1fh7Zx7Bo3p3wy471exUCvOHZ2Y/5hK3sod7TZnyveNgsMf K6BpVFANq4Dph1CoOeco49pLmlPu42jzE5NIhGQSOCDcA+3DFpp5nnzX8nrXoxJ8xP95 p0Tdv1Yh75tIhKAy+VRBoEvf/K8bz+obOKLPo= 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=qqxUucaW6eXNxxN3QKf5ViXnW4pqM4UoFCZMv0aqmiPDoa/W2z9Jvtu7Nan/8ZyUWS 4e71wg0Y5zPNFTJQ+xonj1NOMhrO6pTEp5FDkOcCgqzhxQW+oytOvJ2Hrbc2/YYkt9LV sWoRLvW/WloDI6LdI98UiZ1sBzrRJPd0IqAos= Received: by 10.213.96.202 with SMTP id i10mr4469774ebn.99.1260848764873; Mon, 14 Dec 2009 19:46:04 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 15sm3440779ewy.8.2009.12.14.19.46.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 19:46:03 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B27067A.8020906@jacaranda.org> Date: Tue, 15 Dec 2009 03:46: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: <200912141911.nBEJBmMr014961@fs4113.wdf.sap.corp> In-Reply-To: <200912141911.nBEJBmMr014961@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFED4C0681D24082081913779" Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2009 03:46:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFED4C0681D24082081913779 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > Yngve Nysaeter Pettersen wrote: >> I am talking about a client, as all current Browser clients, that have= to =20 >> allow the use of non-extension handshakes because of interoperability = =20 >> reasons. >> >> In that *particular* situation, when it does not know that it is about= to =20 >> talk to an RI patched server. Upon discovering that it is indeed RI =20 >> patched, based on my suggestions for requireiement the client knows tw= o =20 >> additional things: 1) It can use the RI extension with this server, an= d 2) =20 >> it have to make sure that it was not forced to use an older SSL/TLS =20 >> version than it supports. Therefore it should tear down the connection= and =20 >> re-establish it, in Opera's case signalling support for TLS 1.2 and us= ing =20 >> the RI extension, and (again assuming my proposal is accepted) the ser= ver =20 >> will accept the hello, respond with a RI extension and its highest =20 >> supported version if it is lower than Opera's, and Opera's if the serv= er =20 >> supports a newer version. If the handshake fails in this situation =20 >> somebody is trying to perform a version rollback attack against the cl= ient. >=20 > That is _not_ a version rollback attack (on the TLS protocol version), > but instead a downgrade attack on your fallback logic. It is unrelated= > to the TLS renegotiation vulnerability. How should a client prevent such a downgrade attack, in the presence of version-intolerant servers? The renegotiation vulnerability provides an opportunity to get rid of fallbacks in the medium term, because there will be strict clients that only connect to servers patched against that vulnerability. If *all* servers that are patched against the vulnerability are version-tolerant, then such clients don't need fallbacks. That leaves lenient clients that currently do not connect with their highest supported protocol version, for which Yngve's suggestion of reconnecting with the highest supported version is relevant. If you have an alternative proposal that achieves the same security properties for such clients with comparable efficiency and interoperability, let's hear it. > Going through a handshake failure would be a fairly broken solution > and can not possibly work at the TLS protocol level. The clients that perform fallbacks are not working entirely at the TLS protocol level anyway. > What you could use is either the MS SGC logic (which internally > restarts the handshake mid-way), Is that compliant to the spec? It sounds no simpler than dropping the connection and reconnecting, and could cause its own interoperability failures. > or successfully complete the handshake and renegotiate immediately > after with better features. That involves greater overhead and more round-trips. > Any form of handshake failure, reconnect and new handshake will > require apps-level support for this. The only case in which such a reconnection would occur is where such apps-level support already exists. No-one is suggesting adding fallbacks to implementations that do not already use them. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFED4C0681D24082081913779 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/ iF4EAREIAAYFAksnBoEACgkQWUc8YzyzqAeqzwD7BEdwV76f5Xjju4SvRKDGIyCC wV7tPVPIouB7aweafMQBAJ9ssIhzBKudd4hHLWeQDSOwf/GkCIZD1STABlR90tVT =+Sf5 -----END PGP SIGNATURE----- --------------enigFED4C0681D24082081913779-- From djhopwood@googlemail.com Mon Dec 14 19:51: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 34A033A6870 for ; Mon, 14 Dec 2009 19:51: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 8VvWGqjBtx8R for ; Mon, 14 Dec 2009 19:51: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 146753A67E1 for ; Mon, 14 Dec 2009 19:51:47 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1007313eyd.51 for ; Mon, 14 Dec 2009 19:51: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=O1YyRektnDme2yCz8Xx6UxxZalJKjvxAGaD+dIJMsLs=; b=eY6tde1K+DltMY1+4UioYl3wkR9Kf9WMhy6mT4dPICYcpDYj2uCYSbdWAap+J94jSC 0dKIgGtGGtJP14d9wHrj91kmUIR0zdEilq0EPYgxwV9PeXeSh9uEFlsnaNuUgVC3P5d5 hHl2Uksiv8LnopJu7FTBZvpE6475oduyWczXk= 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=BB9QVUp2w1FxdToTM0ln1hZ/yB3B1h/tf/6BSOSlLKVU/SkdVA8DnpW1M/LCD5wDsI h4SeH7tSb0ZNm0xMUB7zlpt3Yi4LcjOtqqO02OSqxPOkhAkhcUXubu8qehBUnhxpdLnx lvByBe/xdXGyOqLjS9oA6F3uE6c2XXkOrUbU0= Received: by 10.213.43.195 with SMTP id x3mr4584333ebe.19.1260849091484; Mon, 14 Dec 2009 19:51:31 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 13sm3457694ewy.1.2009.12.14.19.51.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 19:51:30 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2707C8.1000505@jacaranda.org> Date: Tue, 15 Dec 2009 03:51:36 +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: <200912141911.nBEJBmMr014961@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig03A27E70FE54BDF1F9254993" Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2009 03:51:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig03A27E70FE54BDF1F9254993 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yngve Nysaeter Pettersen wrote: > On Mon, 14 Dec 2009 20:11:48 +0100, Martin Rex wrote: >=20 >> What you could use is either the MS SGC logic (which internally >> restarts the handshake mid-way), or successfully complete the >> handshake and renegotiate immediately after with better features. >=20 > Not a good idea since it requires that the server knows about it. MS wa= s > in charge of both sides for SGC. Indeed, when MS SGC was first implemented, it completely broke interoperability: # Web clients may fail to connect to Web sites that use Server Gated # Cryptography (SGC) for strong encryption when a secure connection is # required. If either the Internet server or Web client is running Micros= oft # products, then the connection may fail. If the Internet server and Web # client are both running Microsoft products, then no problem occurs. I don't know how this was fixed, but it seems as though encouraging the use of an MS SGC-style protocol in other implementations is just asking for more interoperability problems. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig03A27E70FE54BDF1F9254993 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/ iF4EAREIAAYFAksnB8kACgkQWUc8YzyzqAdy0gD/TjVsXh47C+tQvu9ml56N7nEu 96RbYelzu8y/+OWjS0IA/3gTaT8JxGKOB2Jlxh5LKNSbSfvPHdTScHs5ED0sMFO5 =MZn9 -----END PGP SIGNATURE----- --------------enig03A27E70FE54BDF1F9254993-- From ynir@checkpoint.com Tue Dec 15 00:21: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 DF0CA3A697D for ; Tue, 15 Dec 2009 00:21:43 -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.415, BAYES_00=-2.599, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a30zAdSJAFHD for ; Tue, 15 Dec 2009 00:21:40 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6ECD83A67BD for ; Tue, 15 Dec 2009 00:21:39 -0800 (PST) X-CheckPoint: {4B27463B-10001-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7C8BE29C009; Tue, 15 Dec 2009 10:21:24 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6781129C002; Tue, 15 Dec 2009 10:21:24 +0200 (IST) X-CheckPoint: {4B27463A-10002-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBF8LOT7026344; Tue, 15 Dec 2009 10:21: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; Tue, 15 Dec 2009 10:21:34 +0200 From: Yoav Nir To: David-Sarah Hopwood Date: Tue, 15 Dec 2009 10:21:20 +0200 Thread-Topic: [TLS] Closing some open comments on draft-ietf-tls-renegotiation Thread-Index: Acp9X5ymI0N+5Xo+SrSDShpZg3y9Vg== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com> <4B26F86D.4020601@jacaranda.org> In-Reply-To: <4B26F86D.4020601@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 Cc: "tls@ietf.org" Subject: Re: [TLS] Closing some open comments on 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, 15 Dec 2009 08:21:44 -0000 DQpPbiBEZWMgMTUsIDIwMDksIGF0IDQ6NDYgQU0sIERhdmlkLVNhcmFoIEhvcHdvb2Qgd3JvdGU6 DQoNCj4gWW9hdiBOaXIgd3JvdGU6DQo+PiBJdCB3b3VsZCBiZSBlYXN5IHRvIHJlcXVpcmUgdGhp cywgYnV0IGl0J3Mgbm90IGNvbXBsaWFudCB3aXRoIHRoZSBjdXJyZW50DQo+PiBzcGVjLiBUaGUg Y3VycmVudCBzcGVjIHNheXMgdGhhdCB0aGUgZmluaXNoZWQgdmFsdWUgZGVwZW5kcyBvbiBhbGwg dGhlDQo+PiBieXRlcyBzdGFydGluZyB3aXRoIHRoZSBmaXJzdCBieXRlIG9mIHRoZSBDbGllbnRI ZWxsby4NCj4+IA0KPj4gV2UgbWF5IGRvIGp1c3QgdGhhdCBmb3Igc29tZSBmdXR1cmUgdmVyc2lv biBvZiBUTFMgKDEuMz8gMi4wPyA0LjA/KSBidXQNCj4+IGFkZGluZyB0aGUgcHJldmlvdXMgZmlu aXNoZWQgbWVzc2FnZSBpcyBhIGNoYW5nZSB0byB0aGUgc3BlYywgb25lIHRoYXQNCj4+IHJlcXVp cmVzIHNvbWUgc29ydCBvZiBzaWduYWxpbmcsIGVpdGhlciB3aXRoIGEgZmFrZSBjaXBoZXIgc3Vp dGUgb3Igd2l0aA0KPj4gYW4gZXh0ZW5zaW9uLg0KPiANCj4gTm8sIHRoaXMgaXMgYSBtaXN1bmRl cnN0YW5kaW5nOyBjaGFuZ2luZyBob3cgdGhlIEZpbmlzaGVkIG1lc3NhZ2UgaXMNCj4gY29tcHV0 ZWQgKmZvciByZW5lZ290aWF0aW9ucyogZG9lcyBub3QgbmVjZXNzYXJpbHkgcmVxdWlyZSBzaWdu YWxsaW5nLg0KPiANCj4gQ2hhbmdpbmcgdGhlIHdheSB0aGF0IHRoZSBGaW5pc2hlZCBtZXNzYWdl IGlzIGNvbXB1dGVkICpvbmx5KiBmb3INCj4gcmVuZWdvdGlhdGlvbnMsIHdvdWxkIGFmZmVjdCBp bnRlcm9wZXJhYmlsaXR5IG9ubHkgd2hlbiB0aGVyZSBpcyBhDQo+IHJlbmVnb3RpYXRpb24gd2hl cmUgb25lIHBlZXIgaXMgdW5wYXRjaGVkIGFuZCB0aGUgb3RoZXIgaXMgcGF0Y2hlZC4NCj4gVW5k ZXIgdGhhdCBjb25kaXRpb24sIGJlaW5nIGludGVyb3BlcmFibGUgd291bGQgYWxsb3cgYW4gYXR0 YWNrLg0KDQpUaGF0IGlzIGp1c3Qgd3JvbmcuIEFuIFJGQyBjb21wbGlhbnQgY2xpZW50IG5lZ290 aWF0aW5nIHdpdGggYW4gUkZDIGNvbXBsaWFudCBzZXJ2ZXIgbXVzdCBub3QgZ2V0IGEgd3Jvbmcg RmluaXNoZWQgbWVzc2FnZS4gVGhhdCdzIGNoYW5naW5nIHRoZSBwcm90b2NvbCwgYW5kIGl0IHJl cXVpcmVzIHNpZ25hbGluZyBlaXRoZXIgYnkgYSBuZXcgdmVyc2lvbiBudW1iZXIgb3Igc29tZXRo aW5nIGVsc2UuIFlvdSBjYW4ndCBub3cgY2hhbmdlIHRoZSBiYXNlIDEuMi4NCg0KPiAoU29tZSBo YXZlIGFyZ3VlZCBmb3IgYWxsb3dpbmcgcGF0Y2hlZCBjbGllbnRzIGFuZCBzZXJ2ZXJzIHRvIGZh dm91cg0KPiBpbnRlcm9wZXJhYmlsaXR5IG92ZXIgc2VjdXJpdHkgaW4gdGhpcyBjYXNlLiBJIGRv bid0IGFncmVlIHRoYXQgdGhhdCBpcw0KPiBkZXNpcmFibGUuKQ0KDQpUaGF0J3Mgbm90IGZvciB5 b3UgdG8gZGVjaWRlLiBJdCdzIGZvciB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgdmVuZG9ycywgYW5k IHRoZXkgbWF5IG9yIG1heSBub3QgcGFzcyB0aGlzIGRlY2lzaW9uIHRvIHRoZWlyIGN1c3RvbWVy cy4NCg0KPiBGdXJ0aGVybW9yZSwgY2hhbmdpbmcgdGhlIEZpbmlzaGVkIG1lc3NhZ2Ugb25seSBm b3IgcmVuZWdvdGlhdGlvbnMgaXMNCj4gc3VmZmljaWVudCB0byBwcmV2ZW50IGF0dGFja3MgcHJv dmlkZWQgdGhhdCB0aGUgcmVuZWdvdGlhdGluZyBwZWVyDQo+IGhhcyBiZWVuIHVwZGF0ZWQuDQoN Ckl0J3MgYWxzbyBzdWZmaWNpZW50IHRvIGJyZWFrIHNvbWUgdGhpbmdzLg0KDQo+IEJ5IGl0c2Vs ZiwgaG93ZXZlciwgdGhhdCB3b3VsZCBub3QgYWxsb3cgY2xpZW50cyB0byBkZXRlY3Qgbm9uLXBh dGNoZWQNCj4gc2VydmVycy4gSXQgaXMgbGlrZWx5LCBhbmQgZGVzaXJhYmxlLCB0aGF0IHNvbWUg Y2xpZW50cyB3aWxsIGFkb3B0IGENCj4gInN0cmljdCIgcG9saWN5IGluIHdoaWNoIHRoZXkgZmFp bCBhbiAqaW5pdGlhbCogY29ubmVjdGlvbiB0byBhIG5vbi1wYXRjaGVkDQo+IHNlcnZlci4gVGVj aG5pY2FsbHksIG9ubHkgdGhlIHNlcnZlci0+Y2xpZW50IHNpZ25hbCBpcyBkaXJlY3RseSBuZWNl c3NhcnkNCj4gZm9yIHRoaXMuIFRoZSBjbGllbnQtPnNlcnZlciBzaWduYWwgaXMgbmVlZGVkIHRv IGFsbG93IHRoZSBzZXJ2ZXItPmNsaWVudA0KPiBzaWduYWwgdG8gYmUgc2VudCB3aXRob3V0IHRo ZSBwb3NzaWJpbGl0eSBvZiBicmVha2luZyB1bnBhdGNoZWQgY2xpZW50cy4NCj4gDQo+IChUaGUg Y2xpZW50LT5zZXJ2ZXIgc2lnbmFsIGFsc28gYWxsb3dzIHNlcnZlcnMgdG8gcmVqZWN0IGluaXRp YWwNCj4gY29ubmVjdGlvbnMgZnJvbSB1bnBhdGNoZWQgY2xpZW50cy4gSG93ZXZlciwgaXQncyB1 bmxpa2VseSBpbiBwcmFjdGljZQ0KPiB0aGF0IHNlcnZlcnMgd2lsbCBmb2xsb3cgdGhhdCBwb2xp Y3ksIGFuZCBpdCdzIG5vdCBuZWNlc3NhcnkgdG8gcHJldmVudA0KPiB0aGUgbW9zdCBzZXJpb3Vz IHZhcmlhbnQgb2YgdGhlIGF0dGFjay4pDQo+IA0KPiAtLSANCj4gRGF2aWQtU2FyYWggSG9wd29v ZCAg4pqlICBodHRwOi8vZGF2aWRzYXJhaC5saXZlam91cm5hbC5jb20NCj4gDQoNCg== From Pasi.Eronen@nokia.com Tue Dec 15 01:41: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 BFA5E3A697D; Tue, 15 Dec 2009 01:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 BK-DUKfKMdYD; Tue, 15 Dec 2009 01:41:00 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F043A3A67DD; Tue, 15 Dec 2009 01:40:59 -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 nBF9eUJG009198; Tue, 15 Dec 2009 03:40:45 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 11:40:41 +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); Tue, 15 Dec 2009 11:40:18 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 15 Dec 2009 10:40:17 +0100 From: To: Date: Tue, 15 Dec 2009 10:40:16 +0100 Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation Thread-Index: Acp88pVXS8ladKwGSVWs8F1ytseEeAAAyHZwABzeJzA= Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F16A04@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091214191959.427A53A6A27@core3.amsl.com> <200912142101.nBEL1Vle026550@stingray.missi.ncsc.mil> In-Reply-To: <200912142101.nBEL1Vle026550@stingray.missi.ncsc.mil> 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: 15 Dec 2009 09:40:18.0194 (UTC) FILETIME=[9CAB0720:01CA7D6A] X-Nokia-AV: Clean Cc: tls@ietf.org, iesg@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 09:41:00 -0000 David P. Kemp wrote: > Could a special-purpose identity protection handshake be defined in > a manner that is both simpler and safer than full renegotiation? A couple of years ago, there was a proposal to specify new cipher suites that build identity protection into the handshake (draft-hajjeh-tls-identity-protection), and a proposal that used extensions (draft-urien-badra-eap-tls-identity-protection). But these don't solve what's AFAIK the main use case for=20 renegotiation today: a HTTPS server that doesn't know whether it=20 needs client authentication or not until it sees the URL. Of course, it is not impossible to solve this without renegotiation: one obvious way would be HTTP 401 response + a new HTTP header that means "please retry with TLS client authentication". (I haven't really thought about this, so I'm not saying this would necessarily be a good idea.) Best regards, Pasi (not wearing any hats) From huangmin123@huawei.com Tue Dec 15 02: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 014783A69D0; Tue, 15 Dec 2009 02:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9yLtV0dvvAU; Tue, 15 Dec 2009 02:41:02 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2EBC53A67C0; Tue, 15 Dec 2009 02:41:02 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00MP2WBQC2@szxga04-in.huawei.com>; Tue, 15 Dec 2009 18:40:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00CCJWBQQ4@szxga04-in.huawei.com>; Tue, 15 Dec 2009 18:40:38 +0800 (CST) Received: from h00104745 ([10.27.154.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO00JR3WBP1F@szxml04-in.huawei.com>; Tue, 15 Dec 2009 18:40:38 +0800 (CST) Date: Tue, 15 Dec 2009 18:40:36 +0800 From: Huang Min In-reply-to: To: 'Stefan Santesson' , 'Nicolas Williams' , 'Russ Housley' Message-id: <000601ca7d73$0a0289d0$619a1b0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp9OSrozfSrMVuyTS+SIY0wS6uDkQAMryhg Cc: tls@ietf.org, iesg@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 10:41:03 -0000 =20 Hi, Stefan I don't agree the point that unpatched renegotiation could be still used = and all the problems solved by applications. The vunerability is brought by SSL/TLS protocol itself, it MUST solved = by itslef. We could not give this protocol to other upper applications,and = say: "hi, here is a protocol you could use, but there is a vunerability in = the protocol which can be used for a MITM attack, so you SHOULD do A, B, C, D.....to avoid it, if you want to use this protocol. " It is not responsible.=20 Discarding renegotiation mechanism or fixing the vunerability are both = more acceptable than leaving this problem to upper application layer.=20 regards, Min Huang -----=D3=CA=BC=FE=D4=AD=BC=FE----- Date: Tue, 15 Dec 2009 02:37:01 +0100 From: Stefan Santesson Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation To: Nicolas Williams , Russ Housley Cc: iesg@ietf.org, tls@ietf.org Message-ID: Content-Type: text/plain; charset=3D"US-ASCII" The fact that it is used for legitimate purposes makes me worried about = the consequences of just abandoning it without fixing it. Perhaps a middle way is to not fix it and not to remove it, but simply clarify it's security properties. I'm still not convinced you can't use unpatched renegotiation securely if applications simply don't accept messages sent before completed renegotiation as being delivered under = the context of the renegotiated connection. Other's have suggested the same. /Stefan From Pasi.Eronen@nokia.com Tue Dec 15 02:41: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 11A433A69DB for ; Tue, 15 Dec 2009 02:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_35=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 dPz1qkkHNblP for ; Tue, 15 Dec 2009 02:41:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8D5893A69DA for ; Tue, 15 Dec 2009 02:41:54 -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 nBFAf9Ul004138; Tue, 15 Dec 2009 12:41:35 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 12:41: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); Tue, 15 Dec 2009 12:41:24 +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; Tue, 15 Dec 2009 11:41:19 +0100 From: To: , Date: Tue, 15 Dec 2009 11:41:18 +0100 Thread-Topic: [TLS] Black hole was Re: Analysis of Interop scenarios TLS Thread-Index: Acp81cHsTIjhP9nkRiaZukThH6KmYwAm/wFw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F16ADE@NOK-EUMSG-01.mgdnok.nokia.com> References: <001801ca7bda$3492bfc0$0601a8c0@allison> from "tom.petch" at Dec 13, 9 10:43:00 am <200912141554.nBEFsODa002884@fs4113.wdf.sap.corp> In-Reply-To: <200912141554.nBEFsODa002884@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: 15 Dec 2009 10:41:24.0772 (UTC) FILETIME=[261E6E40:01CA7D73] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Black hole was Re: Analysis of Interop scenarios 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, 15 Dec 2009 10:41:59 -0000 Martin Rex wrote: > tom.petch wrote: > > > > There is a solution. We should require, as part of this patch, > > that upgraded stacks treat a version number that is greater than > > some specified value as also being a signal that the peer is > > upgraded. Then we will be able to drop the MCSV and/or RI as a > > signal from the '3.7' ClientHello. But we do need to include this > > now. >=20 > In theory, you are correct. >=20 > This would, however, require us to effectively standarize the secure > TLS renegotiation for TLSv1.3 (or some specific TLS version in the > future) ahead of time. I don't think this is what Tom was proposing. I understood his proposal to be something like if negotiated_version <=3D 1.2 then: if (CH has MSCV) or (CH has RI) or (CH.proposed_version>1.2): client_supports_secure_renegotiation =3D True include RI in ServerHello else: client_supports_secure_renegotiation =3D False else: # do what the future spec says -- we don't know yet=20 =20 Or in other words: including a version >1.2 in ClientHello would mean the same thing as MSCV or empty RI _when_ the negotiated version is <=3D1.2. (But we wouldn't have to specify the behavior for negotiated version >=3D1.3 at this time.) I agree with Tom that if we want to drop MCSV and RI from the ClientHello some day, we would need to specify this behavior now. But today it would be just more code (and unused code) on the server + an extra test case or two.... so there are both pros and cons. (And at this time, I'm not going to take an opinion either way.) Best regards, Pasi (not wearing any hats) From benl@google.com Tue Dec 15 02:43: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 430C03A69DB; Tue, 15 Dec 2009 02:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.977 X-Spam-Level: X-Spam-Status: No, score=-103.977 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V50EsPNH0BSg; Tue, 15 Dec 2009 02:43:42 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 73DA23A69DA; Tue, 15 Dec 2009 02:43:42 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id nBFAhSRE010636; Tue, 15 Dec 2009 02:43:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260873808; bh=WaWwFqY23gadimMsNGvYdrYAaiU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=YQGsE9tmYIyLWMQsV1TT3i4yBPzyM+6gfxnvanRhkmksPAciDbTjszg8nYPtzbOU9 EW4iiuKRYeNmib3XkvOmg== 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=E+R44kEwQAYO+f5cEWj6p3oT02vMsWMEwWwrQt749OVcQtDDoUyZiDEdnNm/sFIno wvWwAcOwHhgsaFbSt9S5g== Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by wpaz5.hot.corp.google.com with ESMTP id nBFAhPQQ007082; Tue, 15 Dec 2009 02:43:26 -0800 Received: by qw-out-2122.google.com with SMTP id 9so782101qwb.55 for ; Tue, 15 Dec 2009 02:43:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.213 with SMTP id m21mr1214041qck.1.1260873805784; Tue, 15 Dec 2009 02:43:25 -0800 (PST) In-Reply-To: <20091214191959.427A53A6A27@core3.amsl.com> References: <20091214191959.427A53A6A27@core3.amsl.com> Date: Tue, 15 Dec 2009 10:43:25 +0000 Message-ID: <1b587cab0912150243o66a3956dm8fb43b9a0c662769@mail.gmail.com> From: Ben Laurie To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 10:43:43 -0000 On Mon, Dec 14, 2009 at 7:19 PM, Russ Housley wrote: > Comment: > > =A0As a protocol climbs the IETF standards-track maturity ladder, we > =A0sometimes drop features. =A0I would rather see renegotiation dropped > =A0from TLS than see this complexity added to TLS protocol. That would break any website that does per-directory client certificates. Which may not be many, but its far more than zero. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From yngve@opera.com Tue Dec 15 03: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 3F2463A67F0 for ; Tue, 15 Dec 2009 03:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 NMwiJrfr3iMO for ; Tue, 15 Dec 2009 03:31:02 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id F00403A672E for ; Tue, 15 Dec 2009 03:31:01 -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 nBFBSTSs012043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Dec 2009 11:28:36 GMT Date: Tue, 15 Dec 2009 12:30:33 +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: <200912141540.nBEFe3km002000@fs4113.wdf.sap.corp> <4B270269.9040909@jacaranda.org> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4B270269.9040909@jacaranda.org> User-Agent: Opera Mail/9.65 (Win32) Subject: Re: [TLS] RI, TLS Extension tolerance and version tolerance in X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 15 Dec 2009 11:31:03 -0000 On Tue, 15 Dec 2009 04:28:41 +0100, David-Sarah Hopwood wrote: > Yngve Nysaeter Pettersen wrote: >> If the server does not support renegotiation then it might not support >> the extension, but my proposal is that it MUST be TLS Extension >> *tolerant*. I am however suggestion, optionally, that supporting the >> extension should be a MUST in patched servers. > > It has to be a MUST. Otherwise, > - strict clients will unnecessarily abort the handshake when they > don't see the extension. > - lenient clients won't know to reconnect, so rollback attacks are > not necessarily prevented. > I am referring to supporting (recognizing) the RI extension in the Client Hello. Maybe that wasn't clear enough. -- 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 rdugal@certicom.com Tue Dec 15 03:46: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 8CFBA3A694F for ; Tue, 15 Dec 2009 03:46:21 -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 Y8WwBthqVRX5 for ; Tue, 15 Dec 2009 03:46:20 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 7B8A13A6818 for ; Tue, 15 Dec 2009 03:46:20 -0800 (PST) X-AuditID: 0a666446-b7bb5ae000000a04-22-4b2776fea56f Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 94.0C.02564.EF6772B4; Tue, 15 Dec 2009 06:46:06 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 06:46:06 -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: Tue, 15 Dec 2009 06:46:05 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402D31A78@XCH57YKF.rim.net> In-Reply-To: <20091214194431.GO1516@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation Thread-Index: Acp89uvn5Ffw0pyCTDWmUIcpoTCCGwAg/rNQ References: <20091214191959.427A53A6A27@core3.amsl.com> <20091214194431.GO1516@Sun.COM> From: "Robert Dugal" To: X-OriginalArrivalTime: 15 Dec 2009 11:46:06.0102 (UTC) FILETIME=[2F926360:01CA7D7C] X-Brightmail-Tracker: AAAABAAAAZESBPV4EgT2vhIE9r8= Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 11:46:21 -0000 The server based gaming specs require renegotiation periodically in order to= refresh TLS session keys. A lot of the requirements in the gaming specs are to meet legislatorial requ= irements. I'm not sure where the renegotiation requirements come from but it's in the= spec and I suspect they are going to be resistant to dropping it. -- 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 Nicola= s Williams Sent: Monday, December 14, 2009 2:45 PM To: Russ Housley Cc: iesg@ietf.org; tls@ietf.org Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote: > As a protocol climbs the IETF standards-track maturity ladder, we > sometimes drop features. I would rather see renegotiation dropped > from TLS than see this complexity added to TLS protocol. I would like to agree. There's no real-world need to re-negotiate for re-keying nowadays: with the advent of 128-bit block block ciphers there's little need. But re-negotiation remains useful for other purposes. Probably the most obvious ones are optional authentication and privacy protection for client credentials. I'm not sure those are sufficiently useful or important to warrant keeping the feature, but if not then dropping the feature does seem like a better option than fixing it. Nico -- _______________________________________________ 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 mbadra@gmail.com Tue Dec 15 04:01: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 0A1523A69C6 for ; Tue, 15 Dec 2009 04:01:06 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 AdAoZw5eU8Lw for ; Tue, 15 Dec 2009 04:01:05 -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 A3E4C3A69BF for ; Tue, 15 Dec 2009 04:01:04 -0800 (PST) Received: by fxm7 with SMTP id 7so4076263fxm.29 for ; Tue, 15 Dec 2009 04:00:47 -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=RshMRsRfRpOqZoRY9ocT77Pji5QAaKUe85BYoCQN5F4=; b=PPjhweXKDsuwD1aKR/x+7X+ciBPVRUVSjHpf0qT5JlaQ1TU+KksBzgf4MTBKjpcHee 5iuQh11amU2GRPdj2rro3NrpGqx3XLvPXLQL4WkGvTwWuzWzW7WkEjHWK8NvMy/aJgek Og4Hopo8vA+od7Qtrbj9szYfrOAcAT6/Qu+wE= 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=l5wvdTN+fiXuvzxwar/rrPDsocx3dLyLm1sG/9giUviKpzCpc7dl3C89NwmQyGfypv RRUkDzzFOnFtyW7CmWT/x0wTTSejFct51QpUau3ML3TlMMjLQgaPBL4jcPlyObIfxD3x v0h8D1c/HDb4qV8ziofLyd+PKOgXz0hr8BOGc= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.239.145.129 with SMTP id s1mr622931hba.45.1260878446908; Tue, 15 Dec 2009 04:00:46 -0800 (PST) In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402D31A78@XCH57YKF.rim.net> References: <20091214191959.427A53A6A27@core3.amsl.com> <20091214194431.GO1516@Sun.COM> <7E1DF37F1F42AB4E877E492C308E6AC402D31A78@XCH57YKF.rim.net> Date: Tue, 15 Dec 2009 16:00:46 +0400 X-Google-Sender-Auth: 6c11d985521caace Message-ID: From: Badra To: Robert Dugal Content-Type: multipart/alternative; boundary=0016e654fe6eeed5a7047ac3235b Cc: tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 12:01:06 -0000 --0016e654fe6eeed5a7047ac3235b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 15, 2009 at 3:46 PM, Robert Dugal wrote: > The server based gaming specs require renegotiation periodically in order > to refresh TLS session keys. > What about resumed handshake? you don't need a new handshake to refresh your keys Best regards Badra On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote: > > As a protocol climbs the IETF standards-track maturity ladder, we > > sometimes drop features. I would rather see renegotiation dropped > > from TLS than see this complexity added to TLS protocol. > > I would like to agree. There's no real-world need to re-negotiate for > re-keying nowadays: with the advent of 128-bit block block ciphers > there's little need. > > But re-negotiation remains useful for other purposes. Probably the most > obvious ones are optional authentication and privacy protection for > client credentials. I'm not sure those are sufficiently useful or > important to warrant keeping the feature, but if not then dropping the > feature does seem like a better option than fixing it. > > Nico > -- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client 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 immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0016e654fe6eeed5a7047ac3235b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 15, 2009 at 3:46 PM= , Robert Dugal <rdugal@certicom.com> wrote:
The server based gaming specs require renegotiation periodically in order t= o refresh TLS session keys.

What about = resumed handshake? you don't need a new handshake to refresh your keys<= /div>
=A0
Best regards
Badra

On Mon, Dec 14, = 2009 at 11:19:57AM -0800, Russ Housley wrote:
> =A0 As a protocol climbs the IETF standards-track maturity ladder, we<= br> > =A0 sometimes drop features. =A0I would rather see renegotiation dropp= ed
> =A0 from TLS than see this complexity added to TLS protocol.

I would like to agree. =A0There's no real-world need to re-negotiate fo= r
re-keying nowadays: with the advent of 128-bit block block ciphers
there's little need.

But re-negotiation remains useful for other purposes. =A0Probably the most<= br> obvious ones are optional authentication and privacy protection for
client credentials. =A0I'm not sure those are sufficiently useful or important to warrant keeping the feature, but if not then dropping the
feature does seem like a better option than fixing it.

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

---------------------------------------------------------------= ------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.
_________________________________________= ______
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--0016e654fe6eeed5a7047ac3235b-- From rdugal@certicom.com Tue Dec 15 04: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 CA0AE3A69FD for ; Tue, 15 Dec 2009 04:29:35 -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=[AWL=-0.001, 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 FtApDpHfV7v5 for ; Tue, 15 Dec 2009 04:29:28 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 4C6173A67E9 for ; Tue, 15 Dec 2009 04:29:27 -0800 (PST) X-AuditID: 0a401fcb-b7ba8ae000007099-00-4b2781194e1d Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 80.0E.28825.911872B4; Tue, 15 Dec 2009 07:29:13 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 07:29:13 -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_01CA7D82.35B94071" Date: Tue, 15 Dec 2009 07:29:13 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402D31A80@XCH57YKF.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation Thread-Index: Acp9fj3wQxPHPqXPSWu43rKcNj2LAgAAGZKw References: <20091214191959.427A53A6A27@core3.amsl.com> <20091214194431.GO1516@Sun.COM> <7E1DF37F1F42AB4E877E492C308E6AC402D31A78@XCH57YKF.rim.net> From: "Robert Dugal" To: X-OriginalArrivalTime: 15 Dec 2009 12:29:13.0302 (UTC) FILETIME=[35A9C760:01CA7D82] X-Brightmail-Tracker: AAAABAAAAZESBPV4EgT2vhIE9r8= Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 12:29:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7D82.35B94071 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable The GSA spec supports resumption but also requires renegotiation. The spec requires mutual authentication and I believe that the certificates have fairly short lifetimes, definitely far shorter than those used in typical web servers. The spec requires SCEP and there are requirements that when a new certificate is issued it must use a different public key. So on renegotiation there may be new certificates exchanged. And the implementers that I have talked to are establishing all their TLS connections once at startup and not closing them unless they absolutely have to. Maybe GSA would be willing to drop renegotiation requirements, forcing implementers to close and re-establish their connections. I cannot answer that question. But on the other hand adding the RI extension doesn't seems that complex to me. The GSA spec requires TLS 1.0 so implementations should be TLS extension compliant already. I will implement whatever the TLS group feels is the most appropriate action for the renegotiation vulnerability. But we need to be careful about dropping features that may be used in applications/specifications outside of the WEB server/browser world. -- 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 From: mbadra@gmail.com [mailto:mbadra@gmail.com] On Behalf Of Badra Sent: Tuesday, December 15, 2009 7:01 AM To: Robert Dugal Cc: tls@ietf.org Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation On Tue, Dec 15, 2009 at 3:46 PM, Robert Dugal wrote: The server based gaming specs require renegotiation periodically in order to refresh TLS session keys. What about resumed handshake? you don't need a new handshake to refresh your keys Best regards Badra On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote: > As a protocol climbs the IETF standards-track maturity ladder, we > sometimes drop features. I would rather see renegotiation dropped > from TLS than see this complexity added to TLS protocol. I would like to agree. There's no real-world need to re-negotiate for re-keying nowadays: with the advent of 128-bit block block ciphers there's little need. But re-negotiation remains useful for other purposes. Probably the most obvious ones are optional authentication and privacy protection for client credentials. I'm not sure those are sufficiently useful or important to warrant keeping the feature, but if not then dropping the feature does seem like a better option than fixing it. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ 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. ------_=_NextPart_001_01CA7D82.35B94071 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

The GSA spec supports resumption but also requires renegotiation.  

 

The spec requires mutual authentication and I believe that th= e certificates  have fairly short lifetimes, definitely far shorter than those used in typical web servers.

The spec requires SCEP and there are requirements that when a= new certificate is issued it must use a different public key.<= /p>

So on renegotiation there may be new certificates exchanged.=

And the implementers that I have talked to are establishing a= ll their TLS connections once at startup and not closing them unless they absolutely have to.

 

Maybe GSA would be willing to drop renegotiation  requir= ements, forcing implementers to close and re-establish their connections.  I ca= nnot answer that question.

But on the other hand adding the RI extension doesn’t s= eems that complex to me.  The GSA spec requires TLS 1.0 so implementations s= hould be TLS extension compliant already.

 

I will implement whatever the TLS group feels is the most appropriate action for the renegotiation vulnerability.

But we need to be careful about dropping features that may be used in applications/specifications outside of the WEB server/browser world.=

 

--

Robert Dugal       = ;            &nb= sp;    Senior Software Developer

Certicom Corp.       = ;             A Subsidiary of Research In Motion =

rdugal@certicom.com

direct        905.501.3848

fax             905.507.4230

w= ww.certicom.com=

 

From: mbadra@gmail.c= om [mailto:mbadra@gmail.com] On Behalf Of Badra
Sent: Tuesday, December 15, 2009 7:01 AM
To: Robert Dugal
Cc: tls@ietf.org
Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

 

On Tue, Dec 15, 2009 at 3:46 PM, Robert Dugal <rdugal@certicom.com> wrote:<= /o:p>

The server based gaming specs require renegotiation periodically in order to refresh TLS session keys.

 

What about resumed handshake? you don't need a new hand= shake to refresh your keys

 

Best regards

Badra

 

On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote:
>   As a protocol climbs the IETF standards-track maturity ladder, w= e
>   sometimes drop features.  I would rather see renegotiation dropped
>   from TLS than see this complexity added to TLS protocol.

I would like to agree.  There's no real-world need to re-negotiate for<= br> re-keying nowadays: with the advent of 128-bit block block ciphers
there's little need.

But re-negotiation remains useful for other purposes.  Probably the mos= t
obvious ones are optional authentication and privacy protection for
client credentials.  I'm not sure those are sufficiently useful or
important to warrant keeping the feature, but if not then dropping the
feature does seem like a better option than fixing it.

Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
http= s://www.ietf.org/mailman/listinfo/tls

-------------------------------------------------------= --------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmissi= on by unintended recipients is not authorized and may be unlawful.

_______________________________________________
TLS mailing list
TLS@ietf.org
http= s://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. ------_=_NextPart_001_01CA7D82.35B94071-- From dispensa@phonefactor.com Tue Dec 15 07:11: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 D464F3A6A6C; Tue, 15 Dec 2009 07:11: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 x6UPtkfnSTk9; Tue, 15 Dec 2009 07:11:47 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id 151E73A6A47; Tue, 15 Dec 2009 07:11:46 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKSyenJRiEd11802PeNFRk+f4w1V5JWWbt@postini.com; Tue, 15 Dec 2009 07:11:34 PST Received: from 10.10.10.67 ([10.10.10.67]) by pos-exch1.corp.positivenetworks.net ([204.13.120.11]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Dec 2009 15:09:12 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 15 Dec 2009 09:11:32 -0600 From: Steve Dispensa To: Ben Laurie , Russ Housley Message-ID: Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation Thread-Index: Acp9mOJhr7gyAphJOkSxIT7FXXFxyg== In-Reply-To: <1b587cab0912150243o66a3956dm8fb43b9a0c662769@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 15:11:49 -0000 On 12/15/09 4:43 AM, "Ben Laurie" wrote: > On Mon, Dec 14, 2009 at 7:19 PM, Russ Housley wrot= e: >> Comment: >>=20 >> =A0As a protocol climbs the IETF standards-track maturity ladder, we >> =A0sometimes drop features. =A0I would rather see renegotiation dropped >> =A0from TLS than see this complexity added to TLS protocol. >=20 > That would break any website that does per-directory client > certificates. Which may not be many, but its far more than zero. >=20 Also, it breaks support for varying crypto strength requirements (e.g., som= e docs require DES/MD5, some require AES/SHA-1). I certainly wouldn't specify a new system this way, but I'm sure there are existing systems that do this= . -Steve From canetti@tau.ac.il Mon Dec 14 11:26: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 2ECA53A6910; Mon, 14 Dec 2009 11:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvdifclnjKy0; Mon, 14 Dec 2009 11:26:29 -0800 (PST) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id 567793A6855; Mon, 14 Dec 2009 11:26:28 -0800 (PST) Received: from [10.0.0.2] (bzq-80-16-73.red.bezeqint.net [82.80.16.73]) by doar.tau.ac.il (Postfix) with ESMTP id 6B943BEFA; Mon, 14 Dec 2009 21:26:13 +0200 (IST) Message-ID: <4B269153.9070701@tau.ac.il> Date: Mon, 14 Dec 2009 21:26:11 +0200 From: Ran Canetti User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Russ Housley References: <20091214191959.427A53A6A27@core3.amsl.com> In-Reply-To: <20091214191959.427A53A6A27@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Dec 2009 08:17:12 -0800 Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 14 Dec 2009 19:26:30 -0000 Indeed. Or, at least, a strong case should be made why renegotiation (within the same session, from the point of view of the application) is an important feature to preserve. Ran Russ Housley wrote: > Comment: > > As a protocol climbs the IETF standards-track maturity ladder, we > sometimes drop features. I would rather see renegotiation dropped > from TLS than see this complexity added to TLS protocol. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Tue Dec 15 08:31: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 251E43A68ED; Tue, 15 Dec 2009 08:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qg9zjSyDre1; Tue, 15 Dec 2009 08:31: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 5DE3E3A6881; Tue, 15 Dec 2009 08:31: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 1NKaJ3-000FW6-HK; Tue, 15 Dec 2009 16:31:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D2D396678; Tue, 15 Dec 2009 16:31: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: U2FsdGVkX192ZZKCHN1JWEk++MpTwL9HgDyzyBbWTaU= Message-ID: <4B27B9DF.1020300@extendedsubset.com> Date: Tue, 15 Dec 2009 10:31:27 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ran Canetti References: <20091214191959.427A53A6A27@core3.amsl.com> <4B269153.9070701@tau.ac.il> In-Reply-To: <4B269153.9070701@tau.ac.il> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 16:31:40 -0000 Ran Canetti wrote: > Indeed. > > Or, at least, a strong case should be made why renegotiation (within the > same session, from the point of view of the application) is an important > feature to preserve. A large number of systems are currently using it. We don't know exactly, but this might give you an idea: http://www.google.com/search?q=microsoft+iis+client+certificate Do they really need it? Probably some do, some don't. Some installations could rearrange their sites to not need it, and some have more IIS web servers than they could begin to count. Why should we keep renegotiation? Because any spec which "drops" it is just going to be ignored, with the side effect of the industry dropping the IETF rather than the IETF dropping renegotiation. Removing support for (i.e., not fixing) a fundamental and widely-used protocol feature like renegotiation is not an option. - Marsh From stpeter@stpeter.im Tue Dec 15 09:24: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 AE1F73A688F; Tue, 15 Dec 2009 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvs+5E1BtXI1; Tue, 15 Dec 2009 09:24:38 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6FFC33A67A3; Tue, 15 Dec 2009 09:24:38 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E5CE40472; Tue, 15 Dec 2009 10:24:24 -0700 (MST) Message-ID: <4B27C647.2060008@stpeter.im> Date: Tue, 15 Dec 2009 10:24:23 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Marsh Ray References: <20091214191959.427A53A6A27@core3.amsl.com> <4B269153.9070701@tau.ac.il> <4B27B9DF.1020300@extendedsubset.com> In-Reply-To: <4B27B9DF.1020300@extendedsubset.com> 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="------------ms090705070306080600020505" Cc: Ran Canetti , iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 17:24:39 -0000 This is a cryptographically signed message in MIME format. --------------ms090705070306080600020505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/15/09 9:31 AM, Marsh Ray wrote: > Ran Canetti wrote: >> Indeed. >> >> Or, at least, a strong case should be made why renegotiation (within the >> same session, from the point of view of the application) is an important >> feature to preserve. > > A large number of systems are currently using it. We don't know exactly, > but this might give you an idea: > > http://www.google.com/search?q=microsoft+iis+client+certificate > > Do they really need it? Probably some do, some don't. Some installations > could rearrange their sites to not need it, and some have more IIS web > servers than they could begin to count. > > Why should we keep renegotiation? > > Because any spec which "drops" it is just going to be ignored, with the > side effect of the industry dropping the IETF rather than the IETF > dropping renegotiation. Given that the TLS WG list is full of discussion about remaining backward-compatible with SSLv3, it's not clear if the industry is paying attention to the IETF anyway. > Removing support for (i.e., not fixing) a fundamental and widely-used > protocol feature like renegotiation is not an option. I think the question Russ raised is: just how fundamental is TLS renegotiation? And the answer so far seems to be: some deployments seem to use it, but it might not be fundamental. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms090705070306080600020505 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 hvcNAQkFMQ8XDTA5MTIxNTE3MjQyM1owIwYJKoZIhvcNAQkEMRYEFNk2LTm9gSTK2LsJHuss RY/M/tiyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAU3T/xFSgeJfoMIt2RwqE7k0rhk8P9G2MbfqmPLHj QuaXv/ten/nrrHt0to5QKqn7yIUZ5ruwVRH6deddMic77FLNSLbhVaJzEgyM6sAJIXzmimwR SFmjmU3RtX7gO2WNAtm7TSjdDX025Lw4QWTW7ss36fk7F+pkDv5cIQ5lSHWmk8r2ibLX6rVO dgys3rc9hO+JsYj0ap2aVt3b483NTE4tONfakDYKrr3X+XCjfZbbcTY0LzxQGISd+5/nQIAe Jm6z6RGLLzNRUXjIixWZtsbHEyEgehbXE2B7h4AVs8ifZ0scrXkRzVeoD5viWOCahhnuD6Sy YIHpU/FwSYhpEAAAAAAAAA== --------------ms090705070306080600020505-- From mrex@sap.com Tue Dec 15 09:47: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 0EE913A688F; Tue, 15 Dec 2009 09:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 SjLl9+LYbdv9; Tue, 15 Dec 2009 09:47: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 05C023A62C1; Tue, 15 Dec 2009 09:47:43 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBFHlR2t000014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Dec 2009 18:47:27 +0100 (MET) From: Martin Rex Message-Id: <200912151747.nBFHlQsd007923@fs4113.wdf.sap.corp> To: housley@vigilsec.com (Russ Housley) Date: Tue, 15 Dec 2009 18:47:26 +0100 (MET) In-Reply-To: <20091214191959.427A53A6A27@core3.amsl.com> from "Russ Housley" at Dec 14, 9 11:19:57 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: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 17:47:45 -0000 Russ Housley wrote: > > Comment: > > As a protocol climbs the IETF standards-track maturity ladder, we > sometimes drop features. I would rather see renegotiation dropped > from TLS than see this complexity added to TLS protocol. The message that I'm receiving here is that Russ thinks the solution that is currently described in draft-ietf-tls-renegotiation-01 is too complex to be a good solution for this problem. It is up to Russ to distinguish whether he doesn't think the problem is worth solving at all, or whether it is _just_ the solution TLS extension RI that he considers too complex to be an adequate solution to the TLS renegotiation vulnerability. Personally, I do not like the complexity of TLS extension RI either, and as previously indicated would prefer a solution of minimal complexity such as draft-mrex-tls-secure-renegotiation-03 -Martin From djhopwood@googlemail.com Tue Dec 15 13:27: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 0C10A3A68C8 for ; Tue, 15 Dec 2009 13:27: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=[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 Ycv0R9oVWkRY for ; Tue, 15 Dec 2009 13:27:08 -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 DA0CB3A67D3 for ; Tue, 15 Dec 2009 13:27:07 -0800 (PST) Received: by ewy6 with SMTP id 6so336860ewy.29 for ; Tue, 15 Dec 2009 13:26: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=UDfCo+lWQfQBw9nSxd0rTMiLXsGcB3XB8ZIXa5rg27Q=; b=NbpeStbsgIt1OFyYYNXjKXrAePeRo+nODVe9llga7MJRfstkn7HxShQJA8sxNdE9fZ TEmhnbDCFnliZuMjDcXmodiJzNDK9pLzDVzqdktEqem3xqsBJO+ZRLQYvjFtUSt0fHjJ hqToFn80QhkQsF2mu34f55NdEH5z9SWt82fMs= 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=YcYaZQj3y7+l1XZINW0nLUFidXRwzptLv40dYXC18dbZZxfwwT+LgRjzJhUgXh+S7P mpzwLmRekFL8lqVk8MCD7dHup5l0PZny+2qzmbhSDIDYEmpKgJy5N4cGv90U0MCqudCh TyX11PAeid6IWRjgNcDsywB4/VaoxSYj3Phzo= Received: by 10.213.37.73 with SMTP id w9mr5752998ebd.27.1260912409763; Tue, 15 Dec 2009 13:26:49 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 13sm153999ewy.13.2009.12.15.13.26.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Dec 2009 13:26:48 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B27FF05.8010205@jacaranda.org> Date: Tue, 15 Dec 2009 21:26: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: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com> <4B26F86D.4020601@jacaranda.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig6944DE3B965FE756DFF31B29" Subject: Re: [TLS] Closing some open comments on 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, 15 Dec 2009 21:27:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6944DE3B965FE756DFF31B29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > On Dec 15, 2009, at 4:46 AM, David-Sarah Hopwood wrote: >=20 >> Yoav Nir wrote: >>> It would be easy to require this, but it's not compliant with the cur= rent >>> spec. The current spec says that the finished value depends on all th= e >>> bytes starting with the first byte of the ClientHello. >>> >>> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) b= ut >>> adding the previous finished message is a change to the spec, one tha= t >>> requires some sort of signaling, either with a fake cipher suite or w= ith >>> an extension. >> >> No, this is a misunderstanding; changing how the Finished message is >> computed *for renegotiations* does not necessarily require signalling.= >> >> Changing the way that the Finished message is computed *only* for >> renegotiations, would affect interoperability only when there is a >> renegotiation where one peer is unpatched and the other is patched. >> Under that condition, being interoperable would allow an attack. >=20 > That is just wrong. You're mistaken. What I said is precisely correct. > An RFC compliant client negotiating with an RFC compliant > server must not get a wrong Finished message. That is not a requirement. It does not matter whether a handshake failure is due to a mismatch in the Finished messages, or a client or server explicitly aborting because it required that renegotiation is only performed with a patched peer. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig6944DE3B965FE756DFF31B29 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/ iF4EAREIAAYFAksn/xMACgkQWUc8YzyzqAdYAAEAmLVGjO5eogr56+63w+XqOi9N cO55VR7StnPfrRo1lD8A/3dsXAyhxbwRE5+hbDUuUE+xFMxvsXL7gSWWDmUfdW55 =DRfK -----END PGP SIGNATURE----- --------------enig6944DE3B965FE756DFF31B29-- From nelson@bolyard.me Tue Dec 15 15:16: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 76EAD3A67A1 for ; Tue, 15 Dec 2009 15:16: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 GqOvawOne9z4 for ; Tue, 15 Dec 2009 15:16:34 -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 31C563A6405 for ; Tue, 15 Dec 2009 15:16:33 -0800 (PST) Received: (qmail 11707 invoked from network); 15 Dec 2009 23:16:15 -0000 Received: from unknown (192.18.120.70) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 15 Dec 2009 23:16:15 -0000 Message-ID: <4B2818BF.507@bolyard.me> Date: Tue, 15 Dec 2009 15:16:15 -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: Peter Saint-Andre References: <20091214191959.427A53A6A27@core3.amsl.com> <4B269153.9070701@tau.ac.il> <4B27B9DF.1020300@extendedsubset.com> <4B27C647.2060008@stpeter.im> In-Reply-To: <4B27C647.2060008@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ran Canetti , iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 23:16:35 -0000 Peter Saint-Andre wrote: > On 12/15/09 9:31 AM, Marsh Ray wrote: >> Why should we keep renegotiation? >> >> Because any spec which "drops" it is just going to be ignored, with the >> side effect of the industry dropping the IETF rather than the IETF >> dropping renegotiation. > > Given that the TLS WG list is full of discussion about remaining > backward-compatible with SSLv3, it's not clear if the industry is paying > attention to the IETF anyway. There is a small number of individuals in this list who are generating a very high volume of traffic arguing that it is necessary to preserve backward compatibility with servers that are not only SSL 3.0 but a subset thereof that is intolerant of any hello extensions and of client hellos that bear any higher version than 3.0, being unable to successfully negotiate an SSL 3.0 handshake in the presence of either. If one judges purely by the volume of traffic in the list, one might conclude that the industry as a whole is behind that position. But I believe that conclusion would not be supported by an actual poll of vendors of SSL 3.x (including TLS 1.x) server products. I think we are merely hearing from a very vociferous minority who hopes to defeat the current draft by filibuster. >> Removing support for (i.e., not fixing) a fundamental and widely-used >> protocol feature like renegotiation is not an option. > > I think the question Russ raised is: just how fundamental is TLS > renegotiation? And the answer so far seems to be: some deployments seem > to use it, but it might not be fundamental. I believe it is very heavily used in business-to-business https transactions including so-called intranet transactions, where parts of a web site require different authentication than the rest. Several alternatives have been proposed to achieve those same ends without renegotiation, such as using separate logical servers on separate ports each with its own authentication requirements that are enforced on the initial handshake, rather than during renegotiation. These proposals all present numerous challenges, any of which is orders of magnitude greater for the many shops that would need to implement them than merely deploying a "safe" version of renegotiation. Numerous server vendors have expressed that they believe their customers would rather live with the vulnerability than be faced with completely refactoring all their https web sites, and/or multiplying the number of deployed reverse proxies. From Nicolas.Williams@sun.com Tue Dec 15 15: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 A0EFD3A6805; Tue, 15 Dec 2009 15:47:28 -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.137, 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 xBPR029ioIKI; Tue, 15 Dec 2009 15:47:28 -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 1B0E13A67B6; Tue, 15 Dec 2009 15:47:24 -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 nBFNlBrV018491; Tue, 15 Dec 2009 23:47: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 nBFNlAbk002111; Tue, 15 Dec 2009 16:47: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 nBFNWAk3005039; Tue, 15 Dec 2009 17:32:10 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBFNW9hH005038; Tue, 15 Dec 2009 17:32:09 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Dec 2009 17:32:09 -0600 From: Nicolas Williams To: Nelson Bolyard Message-ID: <20091215233208.GF1516@Sun.COM> References: <20091214191959.427A53A6A27@core3.amsl.com> <4B269153.9070701@tau.ac.il> <4B27B9DF.1020300@extendedsubset.com> <4B27C647.2060008@stpeter.im> <4B2818BF.507@bolyard.me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2818BF.507@bolyard.me> User-Agent: Mutt/1.5.7i Cc: Ran Canetti , iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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, 15 Dec 2009 23:47:28 -0000 On Tue, Dec 15, 2009 at 03:16:15PM -0800, Nelson Bolyard wrote: > Peter Saint-Andre wrote: > > I think the question Russ raised is: just how fundamental is TLS > > renegotiation? And the answer so far seems to be: some deployments seem > > to use it, but it might not be fundamental. > > I believe it is very heavily used in business-to-business https transactions > including so-called intranet transactions, where parts of a web site require > different authentication than the rest. Oddly enough, I found out today that an important OpenSolaris component depends on it: the subscription-based software repository known as the "extra" repo. (The OpenSolaris IPS packaging system is layered above HTTP. The extra repo requires user authentication with certs in order to obtain the contents of packages in that repository. Not surprisingly this affects my stance on the issue. Not because the affected technology is my employers (or important to me) as much as because it is a good example of how such applications might arise, therefore an indicator that there may be many more like it. It is clearly simpler (well, for most TLS libraries, given their APIs) to fix re-negotiation than to fix all such applications. Nico -- From mrex@sap.com Tue Dec 15 16:58: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 5C6873A67FB; Tue, 15 Dec 2009 16:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 VsCg1xKneGsX; Tue, 15 Dec 2009 16:58: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 E08BB3A63EC; Tue, 15 Dec 2009 16:58:16 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBG0vwX0007980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 01:57:58 +0100 (MET) From: Martin Rex Message-Id: <200912160057.nBG0vvZw004261@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson Bolyard) Date: Wed, 16 Dec 2009 01:57:57 +0100 (MET) In-Reply-To: <4B2818BF.507@bolyard.me> from "Nelson Bolyard" at Dec 15, 9 03:16: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: canetti@tau.ac.il, iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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: Wed, 16 Dec 2009 00:58:18 -0000 Nelson Bolyard wrote: > > > > Given that the TLS WG list is full of discussion about remaining > > backward-compatible with SSLv3, it's not clear if the industry is paying > > attention to the IETF anyway. more than 90% of the world are on TLSv1.0 + SSLv3 combined. > > There is a small number of individuals in this list who are generating a > very high volume of traffic arguing that it is necessary to preserve > backward compatibility with servers that are not only SSL 3.0 but a subset > thereof that is intolerant of any hello extensions and of client hellos > that bear any higher version than 3.0, being unable to successfully > negotiate an SSL 3.0 handshake in the presence of either. This misrepresents facts. What I am arguing for is that a solution does not need to unnecessarily create interoperability problems that can be easily and reliably avoided. If this solution should be patched into the installed base, then it should address the issues of the installed base! If you think the installed base doesn't matter, then you should rather propose to defer the solution to TLSv1.3. > > If one judges purely by the volume of traffic in the list, one might > conclude that the industry as a whole is behind that position. > But I believe that conclusion would not be supported by an actual > poll of vendors of SSL 3.x (including TLS 1.x) server products. > I think we are merely hearing from a very vociferous minority > who hopes to defeat the current draft by filibuster. The open IETF standards process is about discussing technical issues and providing solutions to technical issues. A few valid technical issues that have been raised against TLS extension RI, and not yet been addressed with sufficient clarity. Some issues were of the type "I can not do this-and-this to my installed base". And some answers have been "Tough luck. My installed base doesn't have that problem and I don't care about yours." This would be OK if we were discussing about optional features of a new protocol. But we are actually discussing about a strongly recommended, backwards-incompatible change to the entire installed base that becomes as mandatory as it can get for protocols that were finalized many many years ago. A broken or incomplete patch that is widely distributed will create much more damage than not shipping a patch at all, and ultimately, a conforming patch based on a broken or incomplete spec will create even worse problems. The TLS renegotiation vulnerability itself is compliant implementations of a vague and defective specification for the renegotiation, and we currently see how painful it is to fix that. No, I do not want to have the IETF ship a solution that is superficially evaluated at best. The fact that so many implementers completely missed the TLS renegotiation vulnerability for over 14 years worries me somewhat. A few implementors who have actually tried to implement both proposed solutions for secure TLS renegotiation have shared their results here. So far their results were very similar. If the original SSLv3 specification had described the TLS renegotiation algorithm in full detail, then the vulnerability would have been obvious from the beginning. It's not very different for the interop problems with the extension data in ClientHello and the protocol versions. Instead of just vaguely mentioning extensibility here or there, a specification will need to spell out its expectations by example in order for implementors to not create tomorrows interop problems today. OpenSSL (in the days of 0.9.4) had nursing problems with the TLSv1.0 protocol version, because the protocol version comparisons were hardwired for major and minor version. Today, OpenSSL is forwards compatible on the minor_version, but the major_version is still hardwired. Netscape 6 had problems sending correct protocol versions according to the workarounds in OpenSSL, and Microsoft had a protocol version problem in renegotiation handshakes. To me, the effectively usable protocol version negotiation in TLS (as inherited from SSLv3) for the installed base is a mess. If they had used a set (like its done with the cipher_suites and compression_methods), then the nursing problems would probably be gone by now. Another drawback from the exitisting version negotiation is that implementations de-facto have to implement all protocol versions, and given budget constraints of todays world, TLSv1.0 is likely the protocol with the highest return-of-investment. Due to a complete lack of guidance about protocol version evolvement, implementers made arbitrary choices which values they considered valid and this is what resulted interop problems we currently face. As a side-effect, the original "version rollback protection" no longer works as expected for clients with re-connect fallbacks and conservative clients. > > >> Removing support for (i.e., not fixing) a fundamental and widely-used > >> protocol feature like renegotiation is not an option. > > > > I think the question Russ raised is: just how fundamental is TLS > > renegotiation? And the answer so far seems to be: some deployments seem > > to use it, but it might not be fundamental. > > I believe it is very heavily used in business-to-business https transactions > including so-called intranet transactions, where parts of a web site require > different authentication than the rest. The issue is more, that those environments where renegotiation was offered to applications and got used, now have a vital dependency on that functionality being available. And while _our_ own installed base has no such dependency on TLS renegotiation, *I* do care for the installed base of others, and would be willing to bear the effort and burden to ship an update for the entire installed base, provided that the operational risk such a backwards-incompatible change means for an installed base of largely unknown usage scenarios is designed to be sufficiently small, and the spec on which this change is based is sufficiently clear as to not create new interoperability problems. There are probably less than 10% of the implementers of SSLv3 and TLS implementations participating the IETF. So any spec we come up with should be sufficiently clear and sufficiently simple that implementors around the world can come up with independent interoperable implementations when all what they have is the RFC document that we publish. While we can not fix all of the problems (like unexpected identity changes) universally at the TLS level, we can fix the most serious problems with a relatively modest change in a central location of the software stack and with a much better prerequisites for applying a consistent fix throughout the entire infrastructure than any approach that all of the affected applications would have to individually pursue. -Martin From mrex@sap.com Tue Dec 15 19:37: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 590F83A68A2; Tue, 15 Dec 2009 19:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Jl0BwMXOrT4C; Tue, 15 Dec 2009 19:37: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 43D023A68A0; Tue, 15 Dec 2009 19:37:47 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBG3bSSo009472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 04:37:28 +0100 (MET) From: Martin Rex Message-Id: <200912160337.nBG3bRSM014247@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 16 Dec 2009 04:37:27 +0100 (MET) In-Reply-To: <200912160057.nBG0vvZw004261@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 16, 9 01:57:57 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: canetti@tau.ac.il, iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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: Wed, 16 Dec 2009 03:37:48 -0000 Martin Rex wrote: > > To me, the effectively usable protocol version negotiation in TLS > (as inherited from SSLv3) for the installed base is a mess. > If they had used a set (like its done with the cipher_suites and > compression_methods), then the nursing problems would probably > be gone by now. Another drawback from the exitisting version > negotiation is that implementations de-facto have to implement > all protocol versions, and given budget constraints of todays > world, TLSv1.0 is likely the protocol with the highest > return-of-investment. Actually, that is likely incorrect SSLv3 is probably still the protocol with the higest return-of-investment. Up to this day, SSLv3 is the _only_ protocol version that will provide almost universal interoperability. There are several hundred million SSL clients out there, which, although capable of extension-less TLSv1.0, have this disabled. That platform is known as Windows XP, and it was sold well into 2009 with brand new hardware of the Netbook type (160 GB disk, 1GB Ram), and that was actually the fastest growing PC market segment. But it isn't any different for Windows 2003 / Windows XP 64-bit, >From the 5 PCs I use (2 at work, 3 at home), 4 are WindowsXPsp3 and one is WindowsXPpro 64-bit. And I use the original MSIE for Online Banking with active content (javascript) enabled, while I use Firefox with active content disabled for web browsing. My family still uses MSIE only. Businesses simply can not afford to _not_ support SSLv3 today. Maybe in a few years. But not now. -Martin From mrex@sap.com Tue Dec 15 19:53: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 15C4B3A6974 for ; Tue, 15 Dec 2009 19:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=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 0JYtDcWwnwEg for ; Tue, 15 Dec 2009 19:53: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 ED1553A695C for ; Tue, 15 Dec 2009 19:53:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBG3rEma011738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 04:53:14 +0100 (MET) From: Martin Rex Message-Id: <200912160353.nBG3rDS5015172@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Wed, 16 Dec 2009 04:53:13 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F16ADE@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 15, 9 11:41:18 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] Black hole was Re: Analysis of Interop scenarios TLS 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, 16 Dec 2009 03:53:32 -0000 Pasi.Eronen@nokia.com wrote: > > Martin Rex wrote: > > tom.petch wrote: > > > > > > There is a solution. We should require, as part of this patch, > > > that upgraded stacks treat a version number that is greater than > > > some specified value as also being a signal that the peer is > > > upgraded. Then we will be able to drop the MCSV and/or RI as a > > > signal from the '3.7' ClientHello. But we do need to include this > > > now. > > > > In theory, you are correct. > > > > This would, however, require us to effectively standarize the secure > > TLS renegotiation for TLSv1.3 (or some specific TLS version in the > > future) ahead of time. > > I don't think this is what Tom was proposing. I understood his > proposal to be something like > > if negotiated_version <= 1.2 then: > if (CH has MSCV) or (CH has RI) or (CH.proposed_version>1.2): > client_supports_secure_renegotiation = True > include RI in ServerHello > else: > client_supports_secure_renegotiation = False > else: > # do what the future spec says -- we don't know yet > > Or in other words: including a version >1.2 in ClientHello would mean > the same thing as MSCV or empty RI _when_ the negotiated version is > <=1.2. (But we wouldn't have to specify the behavior for negotiated > version >=1.3 at this time.) > > I agree with Tom that if we want to drop MCSV and RI from the > ClientHello some day, we would need to specify this behavior now. That would only help to drop the signaling on the initial ClientHello, but for the renegotiation ClientHello, the TLS extension RI band-aid will going to be with us for more than 20 years (considering that SSLv3 is still around after 14 years, and >90% of the installed base is at TLSv1.0 (close to 100% of the servers) today, almost 10 years after TLSv1.0. MCSV from draft-mrex-tls-secure-renegotiation-03 could start disappearing from _ALL_ ClientHellos with the deployment of TLSv1.3 capable Clients. > > But today it would be just more code (and unused code) on the server > + an extra test case or two.... so there are both pros and cons. Since such an option can not be covered in "regular" interop testing at the moment, I tend to agree that it is not worth trying, given the (lack of) interoperability track record of untested TLS protocol features. -Martin From frantz@pwpconsult.com Tue Dec 15 23:37: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 E29B73A67AE for ; Tue, 15 Dec 2009 23:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEn25OSGDMBm for ; Tue, 15 Dec 2009 23:37:44 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id DDC9F3A6808 for ; Tue, 15 Dec 2009 23:37:43 -0800 (PST) Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NKoRu-0007qM-2Y for tls@ietf.org; Wed, 16 Dec 2009 02:37:30 -0500 Date: Tue, 15 Dec 2009 23:38:33 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <200912160353.nBG3rDS5015172@fs4113.wdf.sap.corp> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796fb6859c1683d09919768778b4322366350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.34 Subject: Re: [TLS] Black hole was Re: Analysis of Interop scenarios 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: Wed, 16 Dec 2009 07:37:45 -0000 mrex@sap.com (Martin Rex) on Wednesday, December 16, 2009 wrote: >> But today it would be just more code (and unused code) on the server >> + an extra test case or two.... so there are both pros and cons. > >Since such an option can not be covered in "regular" interop testing >at the moment, I tend to agree that it is not worth trying, given >the (lack of) interoperability track record of untested TLS protocol >features. I would think any test suite for TLS would include a client that indicates it could accept a minor protocol number one larger than the latest standard, and screams loudly should that number be accepted. Testing version negotiation would seem a necessary for any test suite. YMMV. 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 ynir@checkpoint.com Wed Dec 16 00: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 9DB9F3A67F2 for ; Wed, 16 Dec 2009 00:18:30 -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 FehT-w3WfUdk for ; Wed, 16 Dec 2009 00:18:29 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 50B8D3A67D9 for ; Wed, 16 Dec 2009 00:18:29 -0800 (PST) X-CheckPoint: {4B2896F2-10007-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 313C729C00A; Wed, 16 Dec 2009 10:18:15 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0200629C002; Wed, 16 Dec 2009 10:18:14 +0200 (IST) X-CheckPoint: {4B2896F1-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBG8IET7023074; Wed, 16 Dec 2009 10:18:14 +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, 16 Dec 2009 10:18:25 +0200 From: Yoav Nir To: David-Sarah Hopwood Date: Wed, 16 Dec 2009 10:18:10 +0200 Thread-Topic: [TLS] Closing some open comments on draft-ietf-tls-renegotiation Thread-Index: Acp+KFY/yz9bt6w+SOKbPraP3kVQ0g== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com> <4B26F86D.4020601@jacaranda.org> <4B27FF05.8010205@jacaranda.org> In-Reply-To: <4B27FF05.8010205@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] Closing some open comments on 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: Wed, 16 Dec 2009 08:18:30 -0000 On Dec 15, 2009, at 11:26 PM, David-Sarah Hopwood wrote: > Yoav Nir wrote: >> On Dec 15, 2009, at 4:46 AM, David-Sarah Hopwood wrote: >>=20 >>> Yoav Nir wrote: >>>> It would be easy to require this, but it's not compliant with the curr= ent >>>> spec. The current spec says that the finished value depends on all the >>>> bytes starting with the first byte of the ClientHello. >>>>=20 >>>> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) bu= t >>>> adding the previous finished message is a change to the spec, one that >>>> requires some sort of signaling, either with a fake cipher suite or wi= th >>>> an extension. >>>=20 >>> No, this is a misunderstanding; changing how the Finished message is >>> computed *for renegotiations* does not necessarily require signalling. >>>=20 >>> Changing the way that the Finished message is computed *only* for >>> renegotiations, would affect interoperability only when there is a >>> renegotiation where one peer is unpatched and the other is patched. >>> Under that condition, being interoperable would allow an attack. >>=20 >> That is just wrong. >=20 > You're mistaken. What I said is precisely correct. I did not mean "wrong" in the sense of incorrect, but "wrong" in the sense = of something we shouldn't do. >=20 >> An RFC compliant client negotiating with an RFC compliant >> server must not get a wrong Finished message. >=20 > That is not a requirement. It does not matter whether a handshake > failure is due to a mismatch in the Finished messages, or a client or > server explicitly aborting because it required that renegotiation is > only performed with a patched peer. Of course it is. Finished message should never fail to verify, unless there= is a real attack going on. They are there to detect attacks, not to detect= unpatched peers. Detection of unpatched peers or the requirement to patch should be through = signaling or alerts.= From Pasi.Eronen@nokia.com Wed Dec 16 01:55: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 8CA933A6915; Wed, 16 Dec 2009 01:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 CX00Jux-MZuQ; Wed, 16 Dec 2009 01:55:02 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 607483A6851; Wed, 16 Dec 2009 01:55:02 -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 nBG9saao004041; Wed, 16 Dec 2009 03:54:47 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 11:53:59 +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, 16 Dec 2009 11:53: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, 16 Dec 2009 10:53:39 +0100 From: To: , Date: Wed, 16 Dec 2009 10:53:37 +0100 Thread-Topic: draft-ietf-tls-renegotation: next steps Thread-Index: Acp+NaPJVQNIb3TkSxqNhqaNAoncoA== Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F17456@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: 16 Dec 2009 09:53:40.0259 (UTC) FILETIME=[A5262F30:01CA7E35] X-Nokia-AV: Clean Subject: [TLS] draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 09:55:03 -0000 (wearing IETF Security Area Director hat) First of all, I want to say that it's clear that this was an unusual IETF Last Call -- and this was expected, too. Usually a WG document does not go to IETF Last Call until everyone in the WG is happy with it, so most of the time, very little happens during the last call. However, this document addresses an urgent security vulnerability, so as discussed in the Hiroshima TLS WG meeting, it was decided to solicit comments from the TLS WG members and the wider community partly overlapping. This means we've gotten quite a few emails. However, although the volume of emails was large, I was a positively surprised how little disagreement there was. There was basically no disagreement about the functionality (what the spec should do); only about how exactly the functionality should be implemented. And even there, most people agreed on most of the big issues, and the disagreement was mostly about details that, frankly speaking, are not all that important (especially to the users of TLS). Some have even dismissed many of the comments as "aesthetic". =20 I disagree with that -- the discussions were not that different from ordinary discussions in any IETF WG. However, I think it's fair to say that most comments were more about "it could/should be better" than "it won't work". Also, despite the occasionally heated email exchanges, I believe most people agree that getting this security vulnerability fixed quickly is more important than the specific details (as long as the details are not totally unreasonable). Summarizing some open issues: - We seem to have rough consensus that both clients and servers need to be able, if they choose to do so, fully operate with legacy (unpatched) systems, at least for a limited period of time (despite the security implications). This implies the need for some form of "signaling" in both directions, where a patched system can determine if the other end supports the fixed renegotiation or not. (The current draft supports this.) - We seem to have rough consensus that the specification should include some form of C->S signaling that can be used with extension-intolerant servers and/or SSLv2 compatible client hellos. (The current draft has the "magic cipher suite value" for this purpose.) - For S->C signaling, we seem to have rough consensus for a TLS extension in ServerHello. - Whether verify_data should be sent over-the-wire or not: current text (send it over-the-wire) seems to have more support (at least 2/3 vs. 1/3). While the rough consensus is perhaps a bit rougher than we'd normally hope to see, I believe most participants (of either opinion) would prefer making a decision over continuing the discussion until some indeterminate time. So we pick the one with more support. - Whether to prohibit sending the extension (in initial ClientHello), or require the magic cipher suite even if the extension is sent (in initial ClientHello): The consensus is again a bit rougher than we'd normally hope to see, but the current text (either is allowed) has more support (about 2/3 vs. 1/3), so we keep it. And again, I believe most participants prefer make some decision over continuing the discussion. - There was some discussion on whether to add the magic cipher suite to patched renegotiation ClientHellos (in addition to the extension), too. I believe rough consensus is not to do this. - The current draft doesn't clearly say what should be included in legacy (insecure) renegotiation ClientHellos. I am not sure if we have enough clear opinions to call consensus, but keeping it aligned with the initial ClientHello (either MSCV or extension) seems to be one simple approach (but I hope to see the actual text). - Yngve Pettersen proposed explicitly saying that servers that implement this draft must be extension-tolerant (not break if the client sends extensions) and version-tolerant (not break if the client proposes a higher version number than the server supports). It seems these are not new requirements, so this would be an editorial clarification (but being very clear doesn't hurt). - Yngve also proposed adding requirements/recommendations about fall-back/reconnection procedures (to extension-less handshake, or earlier versions). I think the rough consensus is that the document should not mandate or even recommend anything about such fall-back/reconnection procedures (which are mostly not related to renegotiation anyway). - There was discussion about adding another C->S signaling method using the proposed version: if proposed version >=3D 1.3, and the negotiated version is <=3D 1.2, it means the client supports this draft (what happens if negotiated version is >=3D 1.3 would be specified in the TLS 1.3 spec). This would allow TLS >=3D1.3 clients to remove other signaling (magic cipher suite/extension) from initial ClientHellos (but requires extra code in the server). As Tom Petch (and others) noted, if we want to do this, it has to be done now (and can't be done when doing TLS 1.3). There was relatively little support for doing this, and rough consensus seems to keep the spec as is in this regard. - There were some proposals to make the ordering of extensions (in either ClientHello, ServerHello, or both) significant somehow. The rough consensus seems to keep the list unordered. - There was a proposal to change the exact contents of the server's extension. There wasn't much support for this, and rough consensus seems to keep them as-is. - There have been some concerns about the clarity of the specification. I think there's some room for improvement here -- I will work with the editor and WG chair to do something about this. I've asked the document editor to update the draft as soon as possible. The IESG will discuss this document this Thursday (December 17), and I hope we can have an approved specification before Christmas. I realize that not everyone will be happy with these decisions, but in my judgment as Security Area Director, the choices are in line with the rough community opinion, and are technically reasonable (many other choices would have been reasonable, too). In particular, I believe that continuing these discussions until some indeterminate time in 2010 would not be in the best interest of the community (many of whom have expressed that they prefer an OK solution this year, instead of possibly-slightly-improved one next year). Best regards, Pasi From gajek@post.tau.ac.il Wed Dec 16 02:07: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 A6C3E3A692C for ; Wed, 16 Dec 2009 02:07: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU7r1LItYICE for ; Wed, 16 Dec 2009 02:07:35 -0800 (PST) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id CA9D83A6781 for ; Wed, 16 Dec 2009 02:07:33 -0800 (PST) Received: from [10.100.100.23] (wl-fw.cs.tau.ac.il [132.67.97.20]) by doar.tau.ac.il (Postfix) with ESMTP id D3B9CBEFB; Wed, 16 Dec 2009 12:07:16 +0200 (IST) User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 16 Dec 2009 12:06:24 +0200 From: Sebastian Gajek To: Yoav Nir , "tls@ietf.org" Message-ID: Thread-Topic: Closing some open comments on draft-ietf-tls-renegotiation Thread-Index: Acp80/0d4zm97OCPEkiT1QBeYxZnuQAKQs+1AE6ZAaw= In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC523@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3343809984_8545284" Subject: Re: [TLS] Closing some open comments on 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: Wed, 16 Dec 2009 10:07:36 -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_3343809984_8545284 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I totally agree. My suggestion was meant as an alternative to the TLS-renegotiation proposal. One needs to define what is meant by a state that contains all previous session messages. I am not sure whether you need a fake ciphersuite for that. You simply need a mechanisms that tells the parties that TLS session is "alive" (like in the lower layer protocols). I am a little bit worried about using the previous-session finished messages as a sub-session identifier (SUSI) in plain text. Imagine there is in future a higher-layer protocol that allows the attacker to access the TLS transcript (think of a powerful application like AFLEX). Given the attacker the finished values in clear means that he gets a verification oracle for free. I am not saying this leads to a concrete attack. However, this oracle is unnecessary and can be circumvented by the above proposal. "Yoav Nir" wrote 14/12/09 22:35: > It would be easy to require this, but it's not compliant with the current > spec. The current spec says that the finished value depends on all the bytes > starting with the first byte of the ClientHello. > > We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but adding > the previous finished message is a change to the spec, one that requires some > sort of signaling, either with a fake cipher suite or with an extension. > > ________________________________________ > From: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Sebastian Gajek > [gajek@post.tau.ac.il] > Sent: Monday, December 14, 2009 17:42 > To: tls@ietf.org > Subject: [TLS] Closing some open comments on draft-ietf-tls-renegotiation > > Hi there, > > sorry for putting another mail into the long list of TLS renegotiation > mails. I skimmed the TLS-renegotiation draft. Surely, a countermeasure is to > cryptographically link the TLS sessions. There are different approaches to > achieve this goal. I was wondering why you introduce a new cipher suite. > Wouldn't it be easier to require that finished values are a function of all > values received so far (incl. previous TLS sessions or at least their > finished values.) This countermeasure is simple, complies with the present > TLS spec and could result in faster adaption. > > Is there a technicality I am not aware? > > Thx for any feedback. --B_3343809984_8545284 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIL6QYJKoZIhvcNAQcCoIIL2jCCC9YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CZwwggTFMIIELqADAgECAg49SgABAAL2AZ+fCLqHHDANBgkqhkiG9w0BAQUFADB8MQswCQYD VQQGEwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1 c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQSBWSTAeFw0wOTA4MTExMjUzMDBaFw0xMDA4MTIxMjUzMDBaMEwxCzAJBgNVBAYT AklMMRgwFgYDVQQDEw9TZWJhc3RpYW4gR2FqZWsxIzAhBgkqhkiG9w0BCQEWFGdhamVrQHBv c3QudGF1LmFjLmlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1oOc03EOCMfs hP83MB4jl1mf40ym4TGyZe5SjG2o8l2G1NS735XdjUjGbWoONGvQ1J2Iqs2GFVWNoR4TWjPh N7SSx8bqU/w9cvWrAeimk+GIRLmQNBSTL2bBVv3WcTnHHMbJ+zoR+7j9FuxxtZbY83yhdda2 dMJGaY1NkiTVlNfcNqGzX5Iy0ZN+u8KTaGKIAGB6dVyBlmKUUNrL2YK9XlHhvHjhRo5MZMVV UnR7fIMBhHzac9zqAADn05p5SAMDckTsZAuKpAmnPlXeJOHearfWJyM7nbTW33lxsOpkEn45 pfjdPwkLdBvBxNjfQOuUFkcbF5IHrsuIFcJ0ibFWawIDAQABo4IB9DCCAfAwgZcGCCsGAQUF BwEBBIGKMIGHMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NlcnRz ZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9WSS5jcnQwMgYIKwYBBQUHMAGGJmh0 dHA6Ly9vY3NwLlZJLnRjY2xhc3MxLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFE6b9bL7 3Wpr3EoHr8m7ZP8WSyafMAwGA1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEw MjAwBggrBgEFBQcCARYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4G A1UdDwEB/wQEAwIE8DAdBgNVHQ4EFgQU/MTk7LaDw+3M5W50cx2epld9y14wVAYDVR0fBE0w SzBJoEegRYZDaHR0cDovL2NybC5WSS50Y2NsYXNzMS50cnVzdGNlbnRlci5kZS9jcmwvdjIv dGNfY2xhc3MxX0wxX0NBX1ZJLmNybDAzBgNVHSUELDAqBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHBgorBgEEAYI3FAICMB8GA1UdEQQYMBaBFGdhamVrQHBvc3QudGF1LmFjLmls MA0GCSqGSIb3DQEBBQUAA4GBACQtYOhTK/tRjEa/fZcMeVVcTVco1qQP4jWBLDY7ZDymT+6Q 4u0MAT4C/YkJBNNWO3Q00F/kyUyJ/GgYYwQ8sYQl3JYMvXXySKasqMCky0wxQ49Lhaz58GKf HOUSxB9UZufN5p+z7Fz17c02GZn+/CDeDs9ADE1tGDWRP4g1p8+6MIIEzzCCBDigAwIBAgIP AJSwAAEAAmKNtR9u7HJkMA0GCSqGSIb3DQEBBQUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UE CBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIg Zm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50 ZXIuZGUwHhcNMDgwNzE4MTEzODU0WhcNMTAxMjMxMjI1OTU5WjB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIg Q2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBW STCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAlAU/f06WxH4Ws7qwgLm3H6TdpOOwvigI uuyt3Zn2dUzOsfGe9KGWbEuGASUVOEihHOjuCvWZlvHb8a7dfnVIQE1OQ/dtXZTSOf3LEaj3 uhhYD/5xFQoQSzF+9s9fkMv33YS6lwSm1ABW62bfayjd0aL6ep7aYVfDHzCkMCcKQNECAwEA AaOCAhAwggIMMIGOBggrBgEFBQcBAQSBgTB/MEwGCCsGAQUFBzAChkBodHRwOi8vd3d3LnRy dXN0Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzXzFfY2EuY3J0MC8G CCsGAQUFBzABhiNodHRwOi8vb2NzcC50Y2NsYXNzMS50cnVzdGNlbnRlci5kZTAPBgNVHRMB Af8EBTADAQH/MEoGA1UdIARDMEEwPwYJKoIUACwBAQEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6 Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0O BBYEFE6b9bL73Wpr3EoHr8m7ZP8WSyafMIHsBgNVHR8EgeQwgeEwgd6ggduggdiGO2h0dHA6 Ly9jcmwudGNjbGFzczEudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX2NsYXNzXzFfY2EuY3Js hoGYbGRhcDovL3d3dy50cnVzdGNlbnRlci5kZS9DTj1UQyUyMFRydXN0Q2VudGVyJTIwQ2xh c3MlMjAxJTIwQ0EsTz1UQyUyMFRydXN0Q2VudGVyJTIwQUcsb3U9cm9vdGNlcnRzLGRjPXRy dXN0Y2VudGVyLGRjPWRlP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT8wDQYJKoZI hvcNAQEFBQADgYEAbgCkuWfdEuoOLKaN2TxIWzxLppxCvKuRkH8MnZAfqf7otioSOKuH79mP y7B5Avqnp32D92XhLXCkgYJULfcB1wzyp6v8KfSpxDpt1256x9Nx1C/m5mVKzIR0o1rjgNW0 6HciRMu0V1wOJji1AWuIzuRULle6HJ/GjnxXW84zyv4xggIVMIICEQIBATCBjjB8MQswCQYD VQQGEwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1 c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQSBWSQIOPUoAAQAC9gGfnwi6hxwwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEW BBQ5ScL+mh6FtNqD3sv4DjL2VerqsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wOTEyMTYxMDA2MjRaMA0GCSqGSIb3DQEBAQUABIIBAM3ZU2EkJR5NGs2T 77ofopl6As3tF3f7neJ39uUQUxE+mHlpWpQttWtgH87+UsflmyQW5yMSD16JYpoAuKzPmgmS cwUyPJahcTF+Or3EB08ymW9OIfOM+VzdUGveob6NYkgvzYkFq18ZQAZ5UpsAvU69rx3DVKB1 i3AxFJlvIjEWSyb01k+EkM7bYSU6mrxCFndTH6X8GQxgPKBPfPmVIpMu14l1bsYoz21NibnN mrFls7ZSKE4+xD6Fgz+oggV1LNYSN+Z52iePl2e7Pie3M2ADKrlg2fQvOTQKq2S4iG/0q09y M4psJR+VwQo5m6b/TP4TRpfgN6lza3tPf5oyps0= --B_3343809984_8545284-- From mrex@sap.com Wed Dec 16 07:06: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 531753A680F; Wed, 16 Dec 2009 07:06:08 -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 1Ch91kaaN2Hs; Wed, 16 Dec 2009 07:06: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 D94B73A6983; Wed, 16 Dec 2009 07:06:05 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGF5o1x028770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 16:05:50 +0100 (MET) From: Martin Rex Message-Id: <200912161505.nBGF5nxa026040@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Wed, 16 Dec 2009 16:05:49 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 16, 9 10:53:37 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: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps 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, 16 Dec 2009 15:06:08 -0000 Pasi.Eronen@nokia.com wrote: > > - Whether to prohibit sending the extension (in initial ClientHello), > or require the magic cipher suite even if the extension is sent (in > initial ClientHello): The consensus is again a bit rougher than we'd > normally hope to see, but the current text (either is allowed) has > more support (about 2/3 vs. 1/3), so we keep it. And again, I believe > most participants prefer make some decision over continuing the > discussion. I'm sorry for creating a confusion and dispute about this. Allowing the sending of an empty extension RI on initial ClientHello should not be a problem and I would find a MAY perfectly acceptable. The real important thing is, that the inclusion of the MCSV is a MUST, because it will reduce the procotol complexity and robustness and allow absolutely _every_ implementer to save code. > - There was some discussion on whether to add the magic cipher suite > to patched renegotiation ClientHellos (in addition to the extension), > too. I believe rough consensus is not to do this. I have a VERY strong objection to leave out the MCSV from any ClientHellos. It will save everyone code if we mandate the use of MCSV on all ClientHellos including secure renegotiation ClientHellos, and it will make the protocol *MUCH* more foolproof. > > - The current draft doesn't clearly say what should be included in > legacy (insecure) renegotiation ClientHellos. I am not sure if we have > enough clear opinions to call consensus, but keeping it aligned with > the initial ClientHello (either MSCV or extension) seems to be one > simple approach (but I hope to see the actual text). Again, the choice is obvious: MCSV, *NO* extension. Anything else just makes no sense and may obviously cause interop problems for some backwards interop scenarios, because it is a backwards-incompatible change. About the backwards interop scenarios in general: Can we please discontine the misleading terminology "lenient client/server" and instead refer to the specific backwards interop scenarios that we address with a recommendation? (1) updated client allowing initial handshakes with old servers (2) updated client allowing renegotiation handshakes with old servers (3) updated server allowing initial handshakes with old clients (4) updated server allowing renegotiation handshakes with old clients As i previously mentioned, I think that we want to get rid of (4) as fast as we can (SHOULD NOT), hope to get rid of (2) at the end of the transition period (MAY), and leave (1) and (3) completely to the consumers of the technology. I'm strongly opposed to any suggestions to impair (1) or (3) in the solution we ship. > > I realize that not everyone will be happy with these decisions, but in > my judgment as Security Area Director, the choices are in line with > the rough community opinion, and are technically reasonable (many > other choices would have been reasonable, too). In particular, I > believe that continuing these discussions until some indeterminate > time in 2010 would not be in the best interest of the community (many > of whom have expressed that they prefer an OK solution this year, > instead of possibly-slightly-improved one next year). I do not agree to your determination of rough consensus. rfc4677, 5.2 Getting Things Done in a Working Group Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that anyone can join, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong. It just doesn't feel right if some peoples feelings about aesthetics are considered more important than other peoples technical issues. -Martin From mrex@sap.com Wed Dec 16 07:30: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 E6F8E3A69CE for ; Wed, 16 Dec 2009 07:30:21 -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 si+Jm1PAXYXh for ; Wed, 16 Dec 2009 07:30:20 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 876423A69DE for ; Wed, 16 Dec 2009 07:30:18 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGFU1RM001427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 16:30:01 +0100 (MET) From: Martin Rex Message-Id: <200912161530.nBGFU0av027619@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 16 Dec 2009 16:30:00 +0100 (MET) In-Reply-To: <4B227458.9080007@extendedsubset.com> from "Marsh Ray" at Dec 11, 9 10:33:28 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] Analysis of Interop scenarios TLS extension RI w/MCSV 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, 16 Dec 2009 15:30:22 -0000 Marsh Ray wrote: > > I would like for the decisions we make today to allow the MCSV hack to > be retired at some point in the future. MCSV represents extra complexity > that we added as a concession for interoperability with obsolete and > out-of-spec systems. MCSV is a very plain and simple backwards interoperability option, and it will, in fact, make implementations easier (less code), less bits-on-the-wire and more robust. There is not only the wire-protocol to consider, but also the semantics that TLS implementations have been providing to applications in the installed base. When an application has been requesting SSLv3 from its TLS implementation in the past, then it probably did not distinguish it's motivation for doing so -- whether it's a desire to _not_ use TLS extensions, whether it's a desire to not use a higher protocol version in the ClientHello, or whether the application knows that it is trying to connect to an extensions-intolerant server. The fact is, that we have established a specific semantic and level expectation for such a request from the application, and it would be very unwise to lightheartedly change such behaviour in the installed base of largely unknown usage scenarios. Doing the negotiation about updated implementations with MCSV + ServerHelloExtension only will have the least amount of impact on semantics and expectations in the installed base, while providing all the functionality we need to protect unsuspecting communication peers. -Martin From marsh@extendedsubset.com Wed Dec 16 07: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 79A073A68C9 for ; Wed, 16 Dec 2009 07:50:09 -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.294, BAYES_00=-2.599, J_CHICKENPOX_43=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 jm4RsmCi01lw for ; Wed, 16 Dec 2009 07:50: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 968B73A6863 for ; Wed, 16 Dec 2009 07:50:08 -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 1NKw8O-000DWt-TX; Wed, 16 Dec 2009 15:49:53 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9E4806678; Wed, 16 Dec 2009 15:49: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/9Z55OChpOPSEnkvyjYjhpi8pGskYCAVs= Message-ID: <4B29019E.1090909@extendedsubset.com> Date: Wed, 16 Dec 2009 09:49:50 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Martin Rex References: <200912161530.nBGFU0av027619@fs4113.wdf.sap.corp> In-Reply-To: <200912161530.nBGFU0av027619@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] Analysis of Interop scenarios TLS extension RI w/MCSV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 15:50:09 -0000 Martin Rex wrote: > Marsh Ray wrote: >> I would like for the decisions we make today to allow the MCSV hack to >> be retired at some point in the future. MCSV represents extra complexity >> that we added as a concession for interoperability with obsolete and >> out-of-spec systems. > > MCSV is a very plain and simple backwards interoperability option, > and it will, in fact, make implementations easier (less code), > less bits-on-the-wire and more robust. For the record, I have never supported using MCSV as a way for implementors to avoid properly handling extensions or to save bits. I have only supported it to help implementors and applications that did not want to lead off the initial handshake with an extension due to the fact that some servers in the wild enter into a slow fail condition. Allowing receivers of a protocol element to make an assumption (because the sender is supposed to send redundant signals) does not usually end up making things more robust. --- switching to another thread here --- Martin Rex wrote: > Pasi.Eronen@nokia.com wrote: >> - The current draft doesn't clearly say what should be included in >> legacy (insecure) renegotiation ClientHellos. I am not sure if we have >> enough clear opinions to call consensus, but keeping it aligned with >> the initial ClientHello (either MSCV or extension) seems to be one >> simple approach (but I hope to see the actual text). > > Again, the choice is obvious: MCSV, *NO* extension. > > Anything else just makes no sense and may obviously cause interop > problems for some backwards interop scenarios, because it is > a backwards-incompatible change. Martin is right about one thing here. MCSV and/or the extension MUST be sent even on renegotiation hellos in order to avoid a specific attack. It's a scenario that's already broken, but nevertheless it is an attack involving two patched endpoints that can be prevented. The current draft has the following language: > TLS clients which support this draft MUST generate either the > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > cipher suite with every ClientHello. I am hoping that a future revision will reinforce that it applies to even supposed renegotiation hellos in compatible-insecure mode. It's not so obvious to me that extension should not be sent though. Spec'ing that would amount to blessing the behavior of old broken systems. Elsewhere we have left that up to implementors whether or not to send extensions. > About the backwards interop scenarios in general: > > Can we please discontine the misleading terminology "lenient client/server" > and instead refer to the specific backwards interop scenarios that > we address with a recommendation? > > (1) updated client allowing initial handshakes with old servers > (2) updated client allowing renegotiation handshakes with old servers > (3) updated server allowing initial handshakes with old clients > (4) updated server allowing renegotiation handshakes with old clients "Lenient" is the nice word for it, all four of those "backwards interop" scenarios are just plain insecure. - Marsh From mrex@sap.com Wed Dec 16 07:57: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 0A7A03A6863 for ; Wed, 16 Dec 2009 07:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 NGB06Goamp7T for ; Wed, 16 Dec 2009 07:57: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 0572C3A67AB for ; Wed, 16 Dec 2009 07:57:27 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGFvCh4008229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 16:57:13 +0100 (MET) From: Martin Rex Message-Id: <200912161557.nBGFvCqw029366@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Wed, 16 Dec 2009 16:57:12 +0100 (MET) In-Reply-To: from "Yngve N. Pettersen" at Dec 12, 9 09:01:17 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] RI, TLS Extension tolerance and version tolerance in servers 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, 16 Dec 2009 15:57:29 -0000 Yngve N. Pettersen wrote: > > With such a re-iteration a separate requirement could be stated for > clients: When sending the RI Extension they MUST identify the highest > SSL/TLS protocol version they support, and it is a fatal error (no > fallback permitted) if the server refuses to negotiate such a Hello, since > such a refusal must be considered an attempt to perform a version rollback > attack. If you really wanted to retrofit a version rollback attack into the installed base along with secure TLS renegotiation, then I would suggest to piggy-back the information about the highest supported protocol version of the server into the (currently empty) TLS extension Server->Client on the initial handshake. The client (like your favorite browser) can then decide whether it cares and how it cares about not having negotiated a protocol version that it believes to be preferable (you indicated to have fallback re-connect logic, so your browser could even automatically retry instead of nagging the user). -Martin From paul.hoffman@vpnc.org Wed Dec 16 08:22: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 ECBB43A67DF; Wed, 16 Dec 2009 08:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.081, 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 5tyfZ26aAMO3; Wed, 16 Dec 2009 08:22:53 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 42A893A67DB; Wed, 16 Dec 2009 08:22:53 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBGGMamp016229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 09:22:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200912161505.nBGF5nxa026040@fs4113.wdf.sap.corp> References: <200912161505.nBGF5nxa026040@fs4113.wdf.sap.corp> Date: Wed, 16 Dec 2009 08:22:35 -0800 To: mrex@sap.com, Pasi.Eronen@nokia.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 16:22:54 -0000 At 4:05 PM +0100 12/16/09, Martin Rex wrote: >I do not agree to your determination of rough consensus. Are you saying that in general, or are you saying you intend to appeal the decision? The two are quite different. --Paul Hoffman, Director --VPN Consortium From mike-list@pobox.com Wed Dec 16 08:53: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 F04DA3A6774; Wed, 16 Dec 2009 08:53:28 -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 gmcdWbJWRXNU; Wed, 16 Dec 2009 08:53: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 DB0693A67A4; Wed, 16 Dec 2009 08:53: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 B6DEAA70E2; Wed, 16 Dec 2009 11:53: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=y4LcOwyDlKxU Hyvh7C+RDCfDYfg=; b=oz6yZ4GE7opNU4lYFkHPmv/ezEm9kwo30VOY0pw4Hxef ZKJ+7Lm3l67nikIpVgsXvKbhLZvVDCVMWG+uQS1j6ZbCN/jolnxiiEzoZ5ZpT2e9 tXxHjM7XkMJjlNLAlhHMnFYFwF3aeIpCRxu3b1csBs7CVAwGCM0FBQdu3BEfzts= 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=cPH+QH HWlZzApeyMScTVFp3mePLXk7SUT/XPASBGYBAOva97r9TcqO8ZfdUnnWENJf9Ixn EeS6zM9UZgPkd83aM1id6fRm4APFEXsTTSZSDW5tKT6isqThPVkenVHy0iAG4zLI u4GrsQbEPm5NJW+6MTznyD5IMcYVmgefAsl+4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A2B2CA70E1; Wed, 16 Dec 2009 11:53: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 BB68CA70E0; Wed, 16 Dec 2009 11:53:10 -0500 (EST) Message-ID: <4B2910E9.8040106@pobox.com> Date: Wed, 16 Dec 2009 08:55:05 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ietf@ietf.org, tls@ietf.org References: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 7F4F664C-EA63-11DE-A893-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 16:53:29 -0000 Pasi.Eronen@nokia.com wrote: > (wearing IETF Security Area Director hat) > > - Whether to prohibit sending the extension (in initial ClientHello), > or require the magic cipher suite even if the extension is sent (in > initial ClientHello): The consensus is again a bit rougher than we'd > normally hope to see, but the current text (either is allowed) has > more support (about 2/3 vs. 1/3), so we keep it. And again, I believe > most participants prefer make some decision over continuing the > discussion. There is no need to prohibit sending an empty RI in an initial Client Hello. Would a server be required to abort if it received it? That doesn't seem like a good design. I've implemented RI + MCSV and the logic I used was to have a boolean for whether the peer is patched, plus a string to hold the received renegotiation_info. When a ClientHello is being processed, the flag is set to false and the string is cleared. Then if the MCSV is seen in the cipher suite list, the flag is set to true. Then when parsing the extensions, if RI is encountered, the flag is set to true and the renegotiation_info is extracted into the string. There is no need to have special cases for initial vs. renegotiation handshakes. > - There was some discussion on whether to add the magic cipher suite > to patched renegotiation ClientHellos (in addition to the extension), > too. I believe rough consensus is not to do this. There is no need to prohibit sending the MCSV in a renegotiation Client Hello. Using the same logic above, all that it does is flip a bit in the server's state. If the client believes it is doing a renegotiation, then it will also send RI with verify_data, which will get processed as above. > - There was discussion about adding another C->S signaling method > using the proposed version: if proposed version >= 1.3, and the > negotiated version is <= 1.2, it means the client supports this draft > (what happens if negotiated version is >= 1.3 would be specified in > the TLS 1.3 spec). This would allow TLS >=1.3 clients to remove other > signaling (magic cipher suite/extension) from initial ClientHellos > (but requires extra code in the server). As Tom Petch (and others) > noted, if we want to do this, it has to be done now (and can't be done > when doing TLS 1.3). There was relatively little support for doing > this, and rough consensus seems to keep the spec as is in this regard. As a practical matter, any TLS 1.3 code will need to still send RI and MCSV since it will surely encounter older servers for a long while after that spec gets published. So it seems that this is unnecessary. Mike From mrex@sap.com Wed Dec 16 08: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 0D43F3A696B; Wed, 16 Dec 2009 08:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Zrf9gkhS19Nd; Wed, 16 Dec 2009 08:58: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 061EB3A690B; Wed, 16 Dec 2009 08:58:50 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGGwZdr015553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 17:58:35 +0100 (MET) From: Martin Rex Message-Id: <200912161658.nBGGwZDb003213@fs4113.wdf.sap.corp> Orig-To: paul.hoffman@vpnc.org (Paul Hoffman) To: ietf@ietf.org, tls@ietf.org Date: Wed, 16 Dec 2009 17:57:03 +0100 (MET) In-Reply-To: from "Paul Hoffman" at Dec 16, 9 08:22:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps 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, 16 Dec 2009 16:58:52 -0000 Paul Hoffman wrote: > > At 4:05 PM +0100 12/16/09, Martin Rex wrote: > >I do not agree to your determination of rough consensus. > > Are you saying that in general, or are you saying you intend > to appeal the decision? The two are quite different. I believe this still captures my position adquately: http://www.ietf.org/mail-archive/web/tls/current/msg05260.html I do not think there has been a satisfactory decision about the semantics of MCSV. Regrettably, I have added to the confusion myself. by asking for overly strict semantics. Without a specific proposal, I do not even see a base to determine consensus, much less for an appeal. One possible semantic that would address my technical issues would be along these lines: All conforming Clients MUST include the cipher suite value TLS_RENEGO_PROTECTION_REQUEST in the cipher_suites list of _every_ ClientHello handshake message they send. This includes clients that do not implement renegotiation or have it disabled. This cipher suite value MAY appear anywhere in the cipher_suites list. Conforming clients that compose an initial ClientHello handshake messages with other TLS extensions, MAY additionally include an empty TLS extension "renegotiation_info". -Martin From marsh@extendedsubset.com Wed Dec 16 10:42: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 DE6AE3A6A29 for ; Wed, 16 Dec 2009 10:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrJaxKuwPjb6 for ; Wed, 16 Dec 2009 10:42: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 17E9D3A6A27 for ; Wed, 16 Dec 2009 10:42: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 1NKyp9-00066B-Pq; Wed, 16 Dec 2009 18:42:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 93F8D6678; Wed, 16 Dec 2009 18:42: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/t6ETEYSZNIVLH7zrXmL+wwvHAdTuZCTM= Message-ID: <4B292A00.5020901@extendedsubset.com> Date: Wed, 16 Dec 2009 12:42:08 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912161658.nBGGwZDb003213@fs4113.wdf.sap.corp> In-Reply-To: <200912161658.nBGGwZDb003213@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-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 18:42:27 -0000 Martin Rex wrote: > > One possible semantic that would address my technical issues > would be along these lines: > > All conforming Clients MUST include the cipher suite value > TLS_RENEGO_PROTECTION_REQUEST in the cipher_suites list of _every_ > ClientHello handshake message they send. This includes clients that > do not implement renegotiation or have it disabled. This cipher > suite value MAY appear anywhere in the cipher_suites list. > > Conforming clients that compose an initial ClientHello handshake > messages with other TLS extensions, MAY additionally include > an empty TLS extension "renegotiation_info". Current wording http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 > TLS clients which support this draft MUST generate either the > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > cipher suite with every ClientHello. I expect it will be reiterated in the next revision. How does this not address the fundamental issue? (Other than it doesn't provide assistance to an implementation which chooses to conduct an insecure negotiation and subsequent insecure renegotiation with an old unpatched extensions-intolerant server). And if not, does anyone propose wording that substantially improves it without changing the current cryptographic computations (e.g., the PRF inputs)? Short and to the point please! - Marsh From smb@cs.columbia.edu Wed Dec 16 10:57: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 5853D3A69EB; Wed, 16 Dec 2009 10:57:27 -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 s8cUQwz6InfG; Wed, 16 Dec 2009 10:57:26 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 86DB03A6842; Wed, 16 Dec 2009 10:57:26 -0800 (PST) Received: from dyn-209-2-209-237.dyn.columbia.edu (dyn-209-2-209-237.dyn.columbia.edu [209.2.209.237]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBGIv8kQ000120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Dec 2009 13:57:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Wed, 16 Dec 2009 13:57:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Steve Dispensa X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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: Wed, 16 Dec 2009 18:57:27 -0000 On Dec 15, 2009, at 10:11 AM, Steve Dispensa wrote: > On 12/15/09 4:43 AM, "Ben Laurie" wrote: >> On Mon, Dec 14, 2009 at 7:19 PM, Russ Housley = wrote: >>> Comment: >>>=20 >>> As a protocol climbs the IETF standards-track maturity ladder, we >>> sometimes drop features. I would rather see renegotiation dropped >>> from TLS than see this complexity added to TLS protocol. >>=20 >> That would break any website that does per-directory client >> certificates. Which may not be many, but its far more than zero. >>=20 > Also, it breaks support for varying crypto strength requirements = (e.g., some > docs require DES/MD5, some require AES/SHA-1). I certainly wouldn't = specify > a new system this way, but I'm sure there are existing systems that do = this. >=20 I'm hard-put to justify a protocol feature for that scenario. It's not = just improbable, it's probably bad application design -- the performance = differences in the different algorithms are just too small to justify = it, and we don't have to support it just to deal with this niche case. = Ben's scenario is more compelling and bears further thought. --Steve Bellovin, http://www.cs.columbia.edu/~smb From ekr@networkresonance.com Wed Dec 16 11:08: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 DCB5B3A6842; Wed, 16 Dec 2009 11:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, 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 s5wvfNmw0mMZ; Wed, 16 Dec 2009 11:08:21 -0800 (PST) Received: from kilo.networkresonance.com (dhcp-128-107-47-89.cisco.com [128.107.47.89]) by core3.amsl.com (Postfix) with ESMTP id 0C3713A6833; Wed, 16 Dec 2009 11:08:21 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 71BF56C823C; Wed, 16 Dec 2009 11:08:11 -0800 (PST) Date: Wed, 16 Dec 2009 11:08:10 -0800 From: Eric Rescorla To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31F17456@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: <20091216190811.71BF56C823C@kilo.networkresonance.com> Cc: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 19:08:22 -0000 At Wed, 16 Dec 2009 10:53:37 +0100, wrote: > - The current draft doesn't clearly say what should be included in > legacy (insecure) renegotiation ClientHellos. I am not sure if we have > enough clear opinions to call consensus, but keeping it aligned with > the initial ClientHello (either MSCV or extension) seems to be one > simple approach (but I hope to see the actual text). Attached is some candidate text that attempts to implement this. It is possible that un-upgraded servers will request that the client renegotiate. It is RECOMMENDED that clients refuse this renegotiation request. Clients which do so MUST respond to such requests with a "no_renegotiation" alert [RFC 5246 requires this alert to be at the "warning" level.] It is possible that the apparently un-upgraded server is in fact an attacker who is then allowing the client to renegotiate with a different, legitimate, upgraded server. In order to detect this attack, clients which choose to renegotiate MUST provide either the TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their ClientHello. In a legitimate renegotiation with an un-upgraded server, either of these signals will be ignored by the server. However, if the server (incorrectly) fails to ignore extensions, sending the "renegotiation_info" extension may cause a handshake failure. Thus, it is permitted, though NOT RECOMMENDED, for the client to simply send the SCSV. This is the only situation in which clients are permitted to not send the "renegotiation_info" extension in a ClientHello which is used for renegotiation. Note that in the case of this downgrade attack attack above, if this is the initial handshake from the server's perspective, then use of the SCSV from the client precludes detection of this attack by the server. However, the attack will be detected by the client when the server sends an empty "renegotiation_info" extension and the client is expecting one containing the previous verify data. By contrast, if the client sends the "renegotiation_info" extension, then the server will immediately detect the attack. After flip-flopping on this in my head a few times, however, my personal view, is that I think this goes too far in the direction of accomodating broken servers. Sending RI in this instance only creates an interop problem when a server (1) is doing something we know to be really unsafe and (2) can't even ignore extensions correctly. We've seen a number of suggestions that we actually forbid renegotiation in case (1) and while I suspect WG consensus doesn't go that far, it's not clear to me that we need to not only allow it but also compensate for servers which are broken in other respects. So, my preference would be to simply mandate RI with the previous verify_data here as in all other cases. > I've asked the document editor to update the draft as soon as > possible. The IESG will discuss this document this Thursday (December > 17), and I hope we can have an approved specification before > Christmas. I'm working on revisions now. -Ekr From dispensa@phonefactor.com Wed Dec 16 11: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 DA09A3A699D; Wed, 16 Dec 2009 11:48: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=[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 k-HYYAAUManW; Wed, 16 Dec 2009 11:48:01 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 9A18F3A68EB; Wed, 16 Dec 2009 11:48:00 -0800 (PST) Received: from source ([204.13.120.8]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKSyk5YmDFPocMkpcvfDPcGP08R+YLsoY6@postini.com; Wed, 16 Dec 2009 11:47:47 PST Received: from 10.10.10.67 ([10.10.10.67]) by pos-exch1.corp.positivenetworks.net ([204.13.120.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Dec 2009 19:45:24 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 16 Dec 2009 13:47:41 -0600 From: Steve Dispensa To: Steven Bellovin Message-ID: Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation Thread-Index: Acp+iKCvdhwhEcGSQEOMr/GWp7Aqcg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: iesg@ietf.org, tls@ietf.org Subject: Re: [TLS] COMMENT: 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: Wed, 16 Dec 2009 19:48:02 -0000 On 12/16/09 12:57 PM, "Steven Bellovin" wrote: > > On Dec 15, 2009, at 10:11 AM, Steve Dispensa wrote: > >> On 12/15/09 4:43 AM, "Ben Laurie" wrote: >>> On Mon, Dec 14, 2009 at 7:19 PM, Russ Housley wrote: >>>> Comment: >>>> >>>> As a protocol climbs the IETF standards-track maturity ladder, we >>>> sometimes drop features. I would rather see renegotiation dropped >>>> from TLS than see this complexity added to TLS protocol. >>> >>> That would break any website that does per-directory client >>> certificates. Which may not be many, but its far more than zero. >>> >> Also, it breaks support for varying crypto strength requirements (e.g., some >> docs require DES/MD5, some require AES/SHA-1). I certainly wouldn't specify >> a new system this way, but I'm sure there are existing systems that do this. >> > I'm hard-put to justify a protocol feature for that scenario. It's not just > improbable, it's probably bad application design -- the performance > differences in the different algorithms are just too small to justify it, and > we don't have to support it just to deal with this niche case. Ben's scenario > is more compelling and bears further thought. First off, I agree that Ben's scenario is more compelling; what I said is significantly less important in my opinion. That said, I wouldn't think only in terms of "application design." There are other use cases that are considerably more complex from a network infrastructure standpoint that do bear consideration. Think about intercepting load balancers (with a variety of different servers behind them), or about shared hosting accounts (e.g. .htaccess files in public_html directories), or about servers that are hosting different off-the-shelf "web applications" that check the configuration checkboxes differently, and so on. I think this is one of those cases where real-world deployments are messier than we'd like. And, as Marsh has said on other threads, to remove a widely used feature is tantamount to forking the protocol. -Steve From DPKemp@missi.ncsc.mil Wed Dec 16 12: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 B11953A6900 for ; Wed, 16 Dec 2009 12:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 mhZgWe0bPvSN for ; Wed, 16 Dec 2009 12:01:34 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id C15893A67F3 for ; Wed, 16 Dec 2009 12:01:34 -0800 (PST) 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, 16 Dec 2009 15:00:39 -0500 Message-ID: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> In-Reply-To: <4B292A00.5020901@extendedsubset.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [POSSIBLE SPAM] Re: [TLS] draft-ietf-tls-renegotation: next steps Thread-Index: Acp+f7COvwxtpENISPu5YWrLxwi2EQAArVJw References: <200912161658.nBGGwZDb003213@fs4113.wdf.sap.corp> <4B292A00.5020901@extendedsubset.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Dec 2009 20:01:42.0578 (UTC) FILETIME=[964E4920:01CA7E8A] Subject: Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 20:01:35 -0000 Martin's text contradicts the AD's decision ... Pasi wrote: > - There was some discussion on whether to add the magic cipher suite > to patched renegotiation ClientHellos (in addition to the extension), > too. I believe rough consensus is not to do this. In addition, the logic of not permitting RI unless some other extension is used is dubious. A client with no need to cater to servers that are both broken and unpatched should not be forced to gin up some other extension just so it will be allowed to send an empty RI. Put me down in favor of the existing text: > TLS clients which support this draft MUST generate either the > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > cipher suite with every ClientHello. ... with possible addition of "or both" just to be perfectly clear that "either" means or, not exclusive-or. Dave -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Marsh Ray Sent: Wednesday, December 16, 2009 1:42 PM To: mrex@sap.com Cc: tls@ietf.org Subject: [POSSIBLE SPAM] Re: [TLS] draft-ietf-tls-renegotation: next steps Importance: Low Martin Rex wrote: >=20 > One possible semantic that would address my technical issues > would be along these lines: >=20 > All conforming Clients MUST include the cipher suite value > TLS_RENEGO_PROTECTION_REQUEST in the cipher_suites list of _every_ > ClientHello handshake message they send. This includes clients that > do not implement renegotiation or have it disabled. This cipher > suite value MAY appear anywhere in the cipher_suites list. >=20 > Conforming clients that compose an initial ClientHello handshake > messages with other TLS extensions, MAY additionally include > an empty TLS extension "renegotiation_info". Current wording http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 > TLS clients which support this draft MUST generate either the > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > cipher suite with every ClientHello. I expect it will be reiterated in the next revision. How does this not address the fundamental issue? (Other than it doesn't provide assistance to an implementation which chooses to conduct an insecure negotiation and subsequent insecure renegotiation with an old unpatched extensions-intolerant server). And if not, does anyone propose wording that substantially improves it without changing the current cryptographic computations (e.g., the PRF inputs)? Short and to the point please! - Marsh _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Wed Dec 16 12:08: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 8CB323A69D9; Wed, 16 Dec 2009 12:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrmMb+vpd2f5; Wed, 16 Dec 2009 12:08: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 779E23A69B5; Wed, 16 Dec 2009 12:08: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 1NL0As-000B0b-1w; Wed, 16 Dec 2009 20:08:42 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8AAD16678; Wed, 16 Dec 2009 20:08: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/USvuYVD4D80U76pCu6heioE3Im6E0Zzc= Message-ID: <4B293E48.406@extendedsubset.com> Date: Wed, 16 Dec 2009 14:08:40 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Rescorla References: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com> <20091216190811.71BF56C823C@kilo.networkresonance.com> In-Reply-To: <20091216190811.71BF56C823C@kilo.networkresonance.com> 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 Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 20:08:57 -0000 Eric Rescorla wrote: > > It is possible that un-upgraded servers will request that the client > renegotiate. It is RECOMMENDED that clients refuse this > renegotiation request. Clients which do so MUST respond to such > requests with a "no_renegotiation" alert [RFC 5246 requires this > alert to be at the "warning" level.] It is possible that the > apparently un-upgraded server is in fact an attacker who is then > allowing the client to renegotiate with a different, legitimate, > upgraded server. In order to detect this attack, clients which > choose to renegotiate MUST provide either the > TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their > ClientHello. In a legitimate renegotiation with an un-upgraded > server, either of these signals will be ignored by the server. > However, if the server (incorrectly) fails to ignore extensions, > sending the "renegotiation_info" extension may cause a handshake > failure. > Thus, it is permitted, though NOT RECOMMENDED, for the > client to simply send the SCSV. This is the only situation in which > clients are permitted to not send the "renegotiation_info" extension > in a ClientHello which is used for renegotiation. This is bad because it greatly complicates the simple definition of the SCSV as "exactly the same semantics as an empty 'renegotiation_info' extension". In fact, it tends to convey exactly the message that the attacker wants "this is an initial handshake". > Note that in the case of this downgrade attack attack above, if this > is the initial handshake from the server's perspective, then use of > the SCSV from the client precludes detection of this attack by the > server. However, the attack will be detected by the client when the > server sends an empty "renegotiation_info" extension and the client > is expecting one containing the previous verify data. It doesn't seem very robust to me. A very long chain of things have to go just so (some even at the option of the attacker) for the client to detect this attack. > By contrast, > if the client sends the "renegotiation_info" extension, then the > server will immediately detect the attack. > > After flip-flopping on this in my head a few times, You're not the only one. :-) > however, my > personal view, is that I think this goes too far in the direction of > accomodating broken servers. Not so much that we want to specifically not be accommodating, but this case introduces complexities and internal contradictions at the expense of non-crusty clients and servers. There's also something to be said for specifically declining to accommodate things in a spec that are already broken twice or thrice over (depending on which spec you read) in the first place. It's not even fixing things half-way. It may be fixing things one-third-way or not at all depending on your philosophy. IMHO, the IETF shouldn't endorse the making of insecure TLS connections by attempting to secure them poorly. In this case, however, the specs should leave enough room for applications to do that sort of thing on their own if they so choose. But in doing so, application vendors, admins, and users alike should know that they are engaging in risky behavior in public. It's visible on the wire. > Sending RI in this instance only creates > an interop problem when a server (1) is doing something we know to be > really unsafe and (2) can't even ignore extensions correctly. We've > seen a number of suggestions that we actually forbid renegotiation in > case (1) and while I suspect WG consensus doesn't go that far, it's not > clear to me that we need to not only allow it but also compensate for > servers which are broken in other respects. > So, my preference would > be to simply mandate RI with the previous verify_data here as in > all other cases. +1 for simplicity and consistency - Marsh From mrex@sap.com Wed Dec 16 12:32: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 0C7753A6A55; Wed, 16 Dec 2009 12:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 r4PVQkeqOJm3; Wed, 16 Dec 2009 12:32:55 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id E701D3A6918; Wed, 16 Dec 2009 12:32:54 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGKWaAZ006771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 21:32:36 +0100 (MET) From: Martin Rex Message-Id: <200912162032.nBGKWZwc016244@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Wed, 16 Dec 2009 21:32:35 +0100 (MET) In-Reply-To: <4B293E48.406@extendedsubset.com> from "Marsh Ray" at Dec 16, 9 02:08: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, ietf@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps 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, 16 Dec 2009 20:32:56 -0000 First, we need to fix the Definition of the TLS_RENEGO_PROTECTION_REQUEST: This cipher suite value is the Client to Server signal that the client is updated and asks to apply the strict rules of secure renegotiation applied to the current handshake -- no excuses. If SCSV is received by a server on an initial handshake that does not contain a renegotiation_info TLS extension, then the server should apply the same semantics as if it had received an empty TLS extension RI in that ClientHello. Concerning the question what a client should send on a backwards interoperable renegotiation handshake: The rule is "if you can't be good, at least be good at it.". That means if the clients configuration permits old-style renegotiation, then he should NOT try fancy new tricks with that old server on the renegotiation handshake that he didn't do on the initial handshake. i.e. if the client had sent TLS extensions on the initial handshake, there is no problem with _sending_ TLS extension RI on the renegotiation handshake with the old server. However, if the client did _not_ use TLS extensions (but SCSV) on the initial handshake with an old server, then there are only to sensible options for the client on renegotiation: (a) abort when the client doesn't allow old-style renegotiation (b) send an extension-less ClientHello with MCSV on renegotiation. -Martin From mrex@sap.com Wed Dec 16 12:59: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 457CE3A6A03 for ; Wed, 16 Dec 2009 12:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 yB9fHO3VG5zr for ; Wed, 16 Dec 2009 12:59: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 45E833A67EC for ; Wed, 16 Dec 2009 12:59:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGKx7Vj007080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 21:59:07 +0100 (MET) From: Martin Rex Message-Id: <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Wed, 16 Dec 2009 21:59:07 +0100 (MET) In-Reply-To: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> from "Kemp, David P." at Dec 16, 9 03:00: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 Cc: tls@ietf.org Subject: Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next 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, 16 Dec 2009 20:59:24 -0000 Kemp, David P. wrote: > > Martin's text contradicts the AD's decision ... I do not fully agree with the AD's determination of rough consensus. For the MCSV signaling, the real rough consensus is different from what Pasi wrote: http://www.ietf.org/mail-archive/web/tls/current/msg05306.html A mandatory Client->Server signaling through cipher suite may have less fanatic followers by the count of numbers, but technical advantages and _no_ technical objections have been raised against it. The current either cipher suite or empty TLS extension RI signaling may have more "pro", but has significant objections against it because of the ambiguity, increased complexity, a 4x code size burden for old non-rengotiating servers and additional testing complexity. So as far as rough consensus is concerned, it is definitely with the approach I described. This is what the IETF procedures are about. Otherwise we could just go back to counting votes. -Martin From ekr@networkresonance.com Wed Dec 16 13: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 C2C703A68CD for ; Wed, 16 Dec 2009 13:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, 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 yQyHUNw2i66B for ; Wed, 16 Dec 2009 13:31:57 -0800 (PST) Received: from kilo.networkresonance.com (dhcp-128-107-47-89.cisco.com [128.107.47.89]) by core3.amsl.com (Postfix) with ESMTP id 217673A67E5 for ; Wed, 16 Dec 2009 13:31:57 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C5CC26C82B8 for ; Wed, 16 Dec 2009 13:32:02 -0800 (PST) Date: Wed, 16 Dec 2009 13:32: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: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> Subject: [TLS] Updated 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, 16 Dec 2009 21:31:57 -0000 I've just submitted a new draft that is intended to enact most of Pasi's message as well as the noncontroversial editorial comments people have raised. Here is what I know still needs work: - The final resolution to what's sent in the legacy renegotiation case (see Pasi's message and the text I sent earlier). - New text for the identity section in Security considerations. (Pending closure on the list). - Make a pass through for clarity for implementors. (Also, I have some text here that Pasi contributed that I need to work in). If you think you made a comment which is noncontroversial that didn't make it in and/or I screwed up incorporating your comment, please let me know and I'll try to fix. For some reason, the submission tool is forcing manual submission. In the interim you can find it at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate.txt Thanks, -Ekr From marsh@extendedsubset.com Wed Dec 16 14:09: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 330F43A6A8F for ; Wed, 16 Dec 2009 14:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: 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+hLbjvnJvfb for ; Wed, 16 Dec 2009 14:09:19 -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 29D5B3A6A8D for ; Wed, 16 Dec 2009 14:09:19 -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 1NL23M-0005vq-Lv; Wed, 16 Dec 2009 22:09:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 907D96678; Wed, 16 Dec 2009 22:09:02 +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+0s0MkZd8rAISZXaQJLDMOic8kT+DHIfg= Message-ID: <4B295A7E.4080901@extendedsubset.com> Date: Wed, 16 Dec 2009 16:09:02 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> In-Reply-To: <200912162059.nBGKx7Sv017923@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] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 22:09:20 -0000 Martin Rex wrote: > Kemp, David P. wrote: >> Martin's text contradicts the AD's decision ... > > I do not fully agree with the AD's determination of rough consensus. > > For the MCSV signaling, the real rough consensus is different from > what Pasi wrote: > > http://www.ietf.org/mail-archive/web/tls/current/msg05306.html That email is Michael Gray of IBM saying "I do not believe a technical objection to the CipherSuite method has been presented" which is not remotely the same as a real lack of "rough consensus". > A mandatory Client->Server signaling through cipher suite may > have less fanatic followers by the count of numbers, Fanaticism is orthogonal to cardinality. > but technical > advantages and _no_ technical objections have been raised against it. Let me re-state them then. Making SCSV mandatory means that it no longer is the equivalent of an empty extension, which raises the question of exactly what it does mean. Saying it means "I'm updated" is simply begging the question. Sending SCSV with no extension in a renegotiation Hello is a very questionable thing to do. That combination of values is needed for clients that wish to send an _initial_ hello and interoperate with extensions-intolerant servers! Overloading to also mean (and be ambiguous) with "I'm intentionally _renegotiating_ in a manner known to be insecure" is bad. And that is a technical objection. > The current either cipher suite or empty TLS extension RI signaling > may have more "pro", but has significant objections against it > because of the ambiguity, "MUST send this and/or that" is not an ambiguity and you know it. > increased complexity, I disagree, see below. > a 4x code size > burden for old non-rengotiating servers How can a TLS client prove in advance that the server could not have been enticed to renegotiate by a MitM? It is not possible to do in general, and thus no general implementation of the protocol can rely on it for security. I just don't see any explanation other than you are pushing this to save a few lines of code in your own particular circumstance. > and additional testing > complexity. Yes. These additional test cases are unfortunate, but nearly all vendors agreed that it was necessary to have an SCSV option to avoid hitting slow failures connecting to the extensions intolerant servers seen in the wild. If you were so concerned with testing complexity you wouldn't be pushing to make simplifying assumptions in your implementation. Testing all cases is certainly more work than the minimal code to support the one and/or requirement. > So as far as rough consensus is concerned, it is definitely > with the approach I described. The "mandatory SCSV" scheme seems primarily useful if your solution works by modifying the PRF inputs on renegotiation and letting the Finished hash comparisons detect the attack. That method had some merit and was given serious consideration by myself and many others. But again, the reason I could not ultimately support it is because it involved changing the cryptographic calculations. Regardless of whether you or I think that it was done correctly, it is a very very big deal to some important users. It will invoke a formal cryptographic review process which will prevent this solution from being usable by many important sites any time soon. Retro-fitting a "mandatory SCSV" requirement to the RI extension proposal is what introduces the complexity and ambiguity without a well-defined benefit. Here are all the things that have to happen in order for a mandatory SCSV requirement to be of benefit: 1. Client has to be in compatible/insecure mode. 2. Mitm has to impersonate a server of interest to the client. 3. Client does not check Mitm's cert on the initial handshake. 4. Client must be willing to conduct a server-initiated renegotiation (from anonymous server). 5. Legit target server has to be in compatible/insecure mode. If all these things happen, then the complicated protocol change prevents one attack variant but leaves others. In addition, another necessary condition for this to actually be a useful improvement is: 6. Mitm can find no unpatched server of equal or greater value with which to attack the connection of this client. The additional complexity and ambiguity that the "mandatory SCSV" scheme introduces for no real benefit is my technical objection against it. - Marsh From ravi@findravi.com Wed Dec 16 14:17: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 79BD13A6A71 for ; Wed, 16 Dec 2009 14:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xwp+2JA98kCK for ; Wed, 16 Dec 2009 14:17:24 -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 1A17C3A6A5F for ; Wed, 16 Dec 2009 14:17:23 -0800 (PST) Received: by pwi20 with SMTP id 20so990413pwi.29 for ; Wed, 16 Dec 2009 14:17:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.2.25 with SMTP id 25mr1083119wab.103.1261001826080; Wed, 16 Dec 2009 14:17:06 -0800 (PST) Date: Wed, 16 Dec 2009 14:17:06 -0800 Message-ID: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=00504502f52be79887047adfdd2e Subject: [TLS] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 22:17:25 -0000 --00504502f52be79887047adfdd2e Content-Type: text/plain; charset=UTF-8 > >>>> As a protocol climbs the IETF standards-track maturity ladder, we > >>>> sometimes drop features. I would rather see renegotiation dropped > >>>> from TLS than see this complexity added to TLS protocol. > >>> > > And, as Marsh has said on other threads, to remove a widely used feature is > tantamount to forking the protocol. > > -Steve > > A third option is to leave renegotiation in, but create an advisory that explains the semantics; namely, it is indeed a RE negotiation, and SSL/TLS itself is starting from scratch and not making any assumptions about what went before and what came after. A higher layer protocol that chooses to mix and match traffic is making assumptions about guarantees from the SSL/TLS layer that are certainly not "explicitly" being made anywhere. This is not because I think renegotiation should continue to work the way it should; in fact I believe the attack discovered was valuable, and changes discussed on this thread over the last several weeks are valuable and SHOULD be added in --- just that they should be added in to TLS 1.3 and the upgrades should happen in the natural order of things. Those immediately impacted (especially those doing the no-client-auth renego client-auth sequence) should fix at app layer. I am just applying my own gut sense of Occam's Razor on the "harm caused by not fixing until TLS 1.3" versus "harm caused by forcing lots and lots of clients and servers that do not need it" into a significant change. As someone who wore an "operations pager" for too many years, I do not believe in "insignificant" changes. If a developer as much as LOOKS at a disk containing operational code, they will find a way to break it which will not be discovered until much later.... Finally, regardless of where the committee ends up, I believe the recommendation's value in the eyes of those who have to make decisions on "to patch now or to wait until I need to upgrade anyway" if it contains advice on this topic. Anyone reading about this attack from the media will have absolutely no clue as to impact. Anyone who reads the the first documents that came out on this issue ( http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html) would be left with very different perceptions of the magnitude of the impact. This is not unnatural in such matters; great minds usually think differently...., but after all this discussion perhaps a blurb in the draft with advice on who should immediately patch might be useful. Ravi, www.findravi.com --00504502f52be79887047adfdd2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>>> =C2=A0As a protocol climbs the IETF standards-track maturi= ty ladder, we
>>>> =C2=A0sometimes drop features. =C2=A0I would rather see re= negotiation dropped
>>>> =C2=A0from TLS than see this complexity added to TLS proto= col.
>>>

And, as Marsh has said on other threads, to remove a widely used feature is=
tantamount to forking the protocol.

=C2=A0-Steve


A third option is to leave renegotiation in, but= create an advisory that explains the semantics; namely, it is indeed a RE = negotiation, and SSL/TLS itself is starting from scratch and not making any= assumptions about what went before and what came after. A higher layer pro= tocol that chooses to mix and match traffic is making assumptions about gua= rantees from the SSL/TLS layer that are certainly not "explicitly"= ; being made anywhere.

This is not because I think renegotiation should continue to work the w= ay it should; in fact I believe the attack discovered was valuable, and cha= nges discussed on this thread over the last several weeks are valuable and = SHOULD be added in --- just that they should be added in to TLS 1.3 and the= upgrades should happen in the natural order of things. Those immediately i= mpacted (especially those doing the no-client-auth renego client-auth seque= nce) should fix at app layer.

I am just applying my own gut sense of Occam's Razor on=C2=A0 the <= br>"harm caused by not fixing until TLS 1.3"
=C2=A0versus "harm caused by forcing lots and lots of clients and servers that do = not need it"
into a significant change. As someone who wore an "operations pager&qu= ot; for too many years, I do not believe in "insignificant" chang= es. If a developer as much as LOOKS at a disk containing operational code, = they will find a way to break it which will not be discovered until much la= ter....

Finally, regardless of where the committee ends up, I believe the recom= mendation's value in the eyes of those who have to make decisions on &q= uot;to patch now or to wait until I need to upgrade anyway" if it cont= ains advice on this topic. Anyone reading about this attack from the media = will have absolutely no clue as to impact.

Anyone who reads the=C2=A0 the first documents that came out on this is= sue (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and http://www.educatedguesswork.org/2009/11/understanding_the_tls_ren= egoti.html) would be left with very different perceptions of the magnit= ude of the impact. This is not unnatural in such matters; great minds usual= ly think differently...., but after all this discussion perhaps a blurb in = the draft with advice on who should immediately patch might be useful.

Ravi, www.findravi.com

--00504502f52be79887047adfdd2e-- From Nicolas.Williams@sun.com Wed Dec 16 14:20: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 70D313A67AF for ; Wed, 16 Dec 2009 14:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.132, 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 yV6mrlX+HPtp for ; Wed, 16 Dec 2009 14:20:21 -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 1B3CC3A68C8 for ; Wed, 16 Dec 2009 14:20:21 -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 nBGMK6In018638 for ; Wed, 16 Dec 2009 22:20: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 nBGMK61W010897 for ; Wed, 16 Dec 2009 15:20: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 nBGMCZwS005599; Wed, 16 Dec 2009 16:12:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBGMCZLw005598; Wed, 16 Dec 2009 16:12:35 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 16 Dec 2009 16:12:35 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20091216221234.GO1516@Sun.COM> References: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: "Kemp David P." , tls@ietf.org Subject: [TLS] Generic process issues (Re: Re: draft-ietf-tls-renegotation: next) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 22:20:22 -0000 On Wed, Dec 16, 2009 at 09:59:07PM +0100, Martin Rex wrote: > So as far as rough consensus is concerned, it is definitely > with the approach I described. This is what the IETF procedures > are about. Otherwise we could just go back to counting votes. Counting votes is problematic in an open membership organization. Rough consensus determination is a fairly subjective operation. I.e., there's going to be unhappy people no matter what. But rough consensus is much better than elections. IMO we need a process for dealing with vulnerabilities in protocol specifications. Such a process should encourage disclosure to the IAB and IESG, including permission for them to manage further disclosures to other IETF participants, all so as to ensure private discussion of fixes that approximates open discussions and avoids surprising the community with faits accompli or nearly accompli. (Regardless of what one thinks happened in this case, handling of future cases like this one could be horrible without such rules.) Nico -- From root@core3.amsl.com Wed Dec 16 14:30:05 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 693FC3A6A87; Wed, 16 Dec 2009 14:30: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: <20091216223004.693FC3A6A87@core3.amsl.com> Date: Wed, 16 Dec 2009 14:30:02 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-renegotiation-02.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, 16 Dec 2009 22:30:06 -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, N. Oskov, M. Ray, S. Dispensa Filename : draft-ietf-tls-renegotiation-02.txt Pages : 12 Date : 2009-12-16 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 specification 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-16141714.I-D@ietf.org> --NextPart-- From mrex@sap.com Wed Dec 16 14:39: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 4EC323A69FB for ; Wed, 16 Dec 2009 14:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 FfQ5PG6kWknC for ; Wed, 16 Dec 2009 14:39: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 EEED13A68DD for ; Wed, 16 Dec 2009 14:39:04 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBGMcn7g022904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Dec 2009 23:38:49 +0100 (MET) From: Martin Rex Message-Id: <200912162238.nBGMcm1g024244@fs4113.wdf.sap.corp> Orig-To: marsh@extendedsubset.com (Marsh Ray) To: tls@ietf.org Cc: tls@ietf.org Date: Wed, 16 Dec 2009 23:33:36 +0100 (MET) In-Reply-To: <4B295A7E.4080901@extendedsubset.com> from "Marsh Ray" at Dec 16, 9 04:09:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal08 X-SAP: out Subject: Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next 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, 16 Dec 2009 22:39:06 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Kemp, David P. wrote: > >> Martin's text contradicts the AD's decision ... > > > > I do not fully agree with the AD's determination of rough consensus. > > > > For the MCSV signaling, the real rough consensus is different from > > what Pasi wrote: > > > > http://www.ietf.org/mail-archive/web/tls/current/msg05306.html > > That email is Michael Gray of IBM saying "I do not believe a technical > objection to the CipherSuite method has been presented" which is not > remotely the same as a real lack of "rough consensus". you got this wrong. It shows that up to date at least 3 independent people have not noticed that anyone has raised a technical issue against a mandatory SCSV. This particular semantics has always been part of my proposal. > > > but technical > > advantages and _no_ technical objections have been raised against it. > > Let me re-state them then. > > Making SCSV mandatory means that it no longer is the equivalent of an > empty extension, which raises the question of exactly what it does mean. http://www.ietf.org/mail-archive/web/tls/current/msg05372.html > > Sending SCSV with no extension in a renegotiation Hello is a very > questionable thing to do. Nope. The purpose of that cipher suite value, which EKR has cloned from my I-D (including its name), has always been defined as a simple signal Client->Server "Hi, I'm updated", and is meant to imply that an updated server should apply the strict rules of secure renegotiation. > > Sending SCSV with no extension in a renegotiation Hello is a very > questionable thing to do. That combination of values is needed for > clients that wish to send an _initial_ hello and interoperate with > extensions-intolerant servers! Overloading to also mean (and be > ambiguous) with "I'm intentionally _renegotiating_ in a manner known to > be insecure" is bad. And that is a technical objection. Now you're trying to make something up in a haste. I'm wondering which vendors are this that have already shipped an implementation based on the original TLS extension RI proposal and are now trying hard to prevent any changes to the document that would require them to patch again. You are aware that the wording that I proposed does _not_ say that sending a TLS extension RI as the only extension would not be allowed. It is allowed, its up to the vendor. Yes, it would happen that some updated clients send only SCSV and expect the server to understand that. I don't think that is a problem. That update would be with much less time pressure, and then I was assured so many times that sending extensions was so standard and just everybody was doing it already, that I can not believe this to become an unsurmountable problem for early adopters. > > How can a TLS client prove in advance that the server could not have > been enticed to renegotiate by a MitM? It is not possible to do in > general, and thus no general implementation of the protocol can rely on > it for security. I'm sorry, I have no idea what you're talking about. Fixing security problems is not about fixing particular attack scenarios. it is about fixing the defect in the underlying architecture. If there is a unique and uncoditional signal from the client in every ClientHello handshake message that the client is updated and requests the handshake to be performed according to the strict rules of secure renegotiation, then it will be completely impossible for an attacker, independent of any attack scenarios, to make an updated client perform an old handshake with an updated server. That is what fixing the vulnerability at an abstract level is about, and makes the architecture so much simpler and robust, because you do not have to distinguish scenarios. And it is also completely independent of which peer allows which kind of backwards interop. > > I just don't see any explanation other than you are pushing this to save > a few lines of code in your own particular circumstance. Everyone can save those lines! you can remove a lot of conditionals in the code. > > The "mandatory SCSV" scheme seems primarily useful if your solution > works by modifying the PRF inputs on renegotiation and letting the > Finished hash comparisons detect the attack. That method had some merit > and was given serious consideration by myself and many others. No, it is universally useful, and saves everyone code and test complexity. > > The additional complexity and ambiguity that the "mandatory SCSV" scheme > introduces for no real benefit is my technical objection against it. It just doesn't apply and ist _MUCH_ to complicated for a simple design, anyway. -Martin From marsh@extendedsubset.com Wed Dec 16 14:43: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 26D6E3A6AA2 for ; Wed, 16 Dec 2009 14:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIOswN4Ok4mo for ; Wed, 16 Dec 2009 14:43:17 -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 3EC9E3A6A8F for ; Wed, 16 Dec 2009 14:43:17 -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 1NL2aE-000Ifk-Qk; Wed, 16 Dec 2009 22:43:02 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D548C6678; Wed, 16 Dec 2009 22:43: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: U2FsdGVkX1/46ttyS2e6Lr20SA1qcm/lL0JPfqYqTmQ= Message-ID: <4B296275.8010108@extendedsubset.com> Date: Wed, 16 Dec 2009 16:43:01 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ravi Ganesan References: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> In-Reply-To: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@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] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 22:43:18 -0000 Ravi Ganesan wrote: > > A third option is to leave renegotiation in, but create an advisory that > explains the semantics; What do you (as a vendor) tell your customers when they know they are vulnerable and call you for a fix? > namely, it is indeed a RE negotiation, and > SSL/TLS itself is starting from scratch and not making any assumptions > about what went before and what came after. A higher layer protocol that > chooses to mix and match traffic is making assumptions about guarantees > from the SSL/TLS layer that are certainly not "explicitly" being made > anywhere. Netscape's use of renegotiation of from the beginning strongly implies they believed the guarantees were present when they added it to the protocol. There are still ambiguities which indicate an internal inconsistency in the spec. For example, the spec requires that application data be allowed to interleave with the renegotiation handshake messages. There are multiple points during the handshake at which the identity may be considered to have changed with various degrees of authentication. The users on this list with the high-bandwidth links to Jupiter (who were they again?) are quite attached to this feature. > [...] Anyone reading about this attack from the > media will have absolutely no clue as to impact. > > Anyone who reads the the first documents that came out on this issue > (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and > http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html) > would be left with very different perceptions of the magnitude of the > impact. This is not unnatural in such matters; great minds usually think > differently...., but after all this discussion perhaps a blurb in the > draft with advice on who should immediately patch might be useful. In short, everyone* needs to patch and disable compatible/insecure mode as soon as is practical. *Except those who can prove that their endpoint cannot renegotiate and will never be willing to talk to a server that can possibly renegotiate. Or is a protocol that perfectly discards all state on every handshake. This is only possible with direct code inspection and protocol analysis, and in practice experts have been repeatedly surprised by what attacks turns out to be possible. Someone may reply and say "Oh this particular situation doesn't need to patch" but again, it will likely be because some systems accidentally fall into a few narrow categories. - Marsh From mrex@sap.com Wed Dec 16 14:49: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 2F76E3A6840 for ; Wed, 16 Dec 2009 14:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 CTM1Go3euNrW for ; Wed, 16 Dec 2009 14:49: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 1845E3A67AF for ; Wed, 16 Dec 2009 14:49:22 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBGMn7GD021156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Dec 2009 23:49:08 +0100 (MET) From: Martin Rex Message-Id: <200912162249.nBGMn7eI024598@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 16 Dec 2009 23:49:07 +0100 (MET) In-Reply-To: <200912162238.nBGMcm1g024244@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 16, 9 11:33: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 Subject: Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next 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, 16 Dec 2009 22:49:24 -0000 Martin Rex wrote: > > > > > Sending SCSV with no extension in a renegotiation Hello is a very > > questionable thing to do. That combination of values is needed for > > clients that wish to send an _initial_ hello and interoperate with > > extensions-intolerant servers! Overloading to also mean (and be > > ambiguous) with "I'm intentionally _renegotiating_ in a manner known to > > be insecure" is bad. And that is a technical objection. > > Now you're trying to make something up in a haste. > > I'm wondering which vendors are this that have already shipped > an implementation based on the original TLS extension RI proposal > and are now trying hard to prevent any changes to the document > that would require them to patch again. > > > You are aware that the wording that I proposed does _not_ say > that sending a TLS extension RI as the only extension would > not be allowed. It is allowed, its up to the vendor. > > Yes, it would happen that some updated clients send only SCSV and > expect the server to understand that. I don't think that is a problem. > That update would be with much less time pressure, and then I was > assured so many times that sending extensions was so standard and > just everybody was doing it already, that I can not believe this > to become an unsurmountable problem for early adopters. I got confused. It is about early adopter clients that send TLS extension RI (not knowning about SCSV) and might run into updated servers that look only for SCSV. But as I described, these are going to be servers that do not renegotiate anyway, so there even is _no_ security problem involved. Those that implement secure renegotiation will always have to be able to recognize a TLS extension in ClientHello. So really, making up an argument against a mandatory SCSV is going to be tough. -Martin From marsh@extendedsubset.com Wed Dec 16 15:18: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 BD25C3A6AB2 for ; Wed, 16 Dec 2009 15:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hb068989ZtJ for ; Wed, 16 Dec 2009 15:18:38 -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 ADB9D3A67AF for ; Wed, 16 Dec 2009 15:18:38 -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 1NL38S-0003iL-AR; Wed, 16 Dec 2009 23:18:24 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7429C6678; Wed, 16 Dec 2009 23:18: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/8yGsTOimM7ujffN1AoimJhqX1PrV8vZQ= Message-ID: <4B296ABD.8050403@extendedsubset.com> Date: Wed, 16 Dec 2009 17:18:21 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912162249.nBGMn7eI024598@fs4113.wdf.sap.corp> In-Reply-To: <200912162249.nBGMn7eI024598@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] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 23:18:39 -0000 Martin Rex wrote: > Martin Rex wrote: >>> Sending SCSV with no extension in a renegotiation Hello is a very >>> questionable thing to do. That combination of values is needed for >>> clients that wish to send an _initial_ hello and interoperate with >>> extensions-intolerant servers! Overloading to also mean (and be >>> ambiguous) with "I'm intentionally _renegotiating_ in a manner known to >>> be insecure" is bad. And that is a technical objection. >> Now you're trying to make something up in a haste. >> >> I'm wondering which vendors are this that have already shipped >> an implementation based on the original TLS extension RI proposal >> and are now trying hard to prevent any changes to the document >> that would require them to patch again. I don't know of any vendors that have "shipped" an implementation. The closest I know of is OpenSSL has something in their source control system but doubt they would have any problems with whatever changes. Implementing the proposed fix is just not that hard, compared to the difficulty of analyzing the proposals from all angles. >> You are aware that the wording that I proposed does _not_ say >> that sending a TLS extension RI as the only extension would >> not be allowed. It is allowed, its up to the vendor. >> >> Yes, it would happen that some updated clients send only SCSV and >> expect the server to understand that. I don't think that is a problem. >> That update would be with much less time pressure, and then I was >> assured so many times that sending extensions was so standard and >> just everybody was doing it already, that I can not believe this >> to become an unsurmountable problem for early adopters. > > > I got confused. It is about early adopter clients that send > TLS extension RI (not knowning about SCSV) and might run into > updated servers that look only for SCSV. Such servers are not permitted by the current proposal. >From http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt > 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 (the previous > client Finished.verify_data in the ClientHello and the concatenation > of both Finished.verify_data values in the ServerHello). If the > contents are incorrect, then it MUST generate a fatal > "handshake_failure" alert and terminate the connection. [...] > TLS servers MUST support both the "renegotiation_info" extension and > the TLS_RENEGO_PROTECTION_REQUEST SCSV. TLS servers which support > But as I described, > these are going to be servers that do not renegotiate anyway, TLS does not define such a thing as a "server that does not renegotiate". There may be in fact some application protocols or servers which do not, but TLS provide no way to indicate this in the handshake. In practice, it requires deep code inspection to prove and many application authors have been surprised to find out that their TLS implementation will renegotiate for them automatically. Therefore, it is impossible for a general-purpose client to know this about any specific server. Therefore, it is a useless consideration for the protocol design. > so there even is _no_ security problem involved. An unpatched TLS connection can only be believed secure with code inspection done on _both_ endpoints to prove that renegotiation can never happen and/or application protocol analysis. Since a primary feature of TLS is to support interoperability between diverse client and server implementations, this is just not a common enough case to be worth considering. The fact that you are confident that some of your systems are implemented that way is just not a useful consideration in developing a solution for the general case. > Those > that implement secure renegotiation will always have to be able to > recognize a TLS extension in ClientHello. Yes, you will need to be able to recognize one particular extension in order to support the fix for renegotiation. I've proven that that basic code for this can be written in less than an hour, with some test cases. Some organizations may take slightly longer. Organizations which cannot handle that degree of complexity should not IMHO be implementing security protocols. > So really, making up an argument against a mandatory SCSV > is going to be tough. Not really. - Marsh From ravi@findravi.com Wed Dec 16 15:36: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 0B5003A6AA5 for ; Wed, 16 Dec 2009 15:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 bytrTpHrgrYf for ; Wed, 16 Dec 2009 15:36:51 -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 4265B3A67AF for ; Wed, 16 Dec 2009 15:36:51 -0800 (PST) Received: by pwi20 with SMTP id 20so1032410pwi.29 for ; Wed, 16 Dec 2009 15:36:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.132.12 with SMTP id j12mr1136391wan.121.1261006594336; Wed, 16 Dec 2009 15:36:34 -0800 (PST) In-Reply-To: <3561bdcc0912161509j799392d1t2f4f09a7d1184737@mail.gmail.com> References: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> <4B296275.8010108@extendedsubset.com> <3561bdcc0912161509j799392d1t2f4f09a7d1184737@mail.gmail.com> Date: Wed, 16 Dec 2009 15:36:34 -0800 Message-ID: <3561bdcc0912161536y5e240e6cqe414c7d4aa2baef8@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e648f4b21d6704047ae0fa90 Subject: [TLS] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2009 23:36:52 -0000 --0016e648f4b21d6704047ae0fa90 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 16, 2009 at 2:43 PM, Marsh Ray wrote: > Ravi Ganesan wrote: > > > > A third option is to leave renegotiation in, but create an advisory that > > explains the semantics; > > What do you (as a vendor) tell your customers when they know they are > vulnerable and call you for a fix? > > Have TLS 1.3 code ready and tell them to upgrade to it. Asking customers to move to newer release in order to fix security problems is something the market understands. (did not say 'likes'). However, if you are correct in your impact analysis in your original paper, then an emergency patch is the appropriate response. I am not sure I know enough to agree with your impact analysis, but either way, good job done by your team and Martin on this discovery -- it will make TLS 1.3 better. One stat that might allow us to ascertain immediate impact: If I am a web site who strictly ONLY uses server side SSL (with client auth being handled by passwords, etc.), And, I have ability to turn of renego. Will that do the trick? If so what portion of SSL users fall into this use-case? -- Ravi Ganesan ravi@findravi.com www.findravi.com --0016e648f4b21d6704047ae0fa90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Wed, Dec 16, 2009 at 2:43 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
Ravi Ganesan wrote:
>
> A third option is to leave renegotiation in, but create an advisory th= at
> explains the semantics;

What do you (as a vendor) tell your customers when they know they are=
vulnerable and call you for a fix?


Have TLS 1.3 code ready and tell= them to upgrade to it.=C2=A0 Asking customers to move to newer release in = order to fix security problems is something the market understands. (did no= t say 'likes').

However, if you are correct in your impact analysis in your original pa= per, then an emergency patch is the appropriate response. I am not sure I k= now enough to agree with your impact analysis, but either way, good job don= e by your team and Martin on this discovery -- it will make TLS 1.3 better.=

One stat that might allow us=C2=A0 to ascertain immediate impact: If I = am a web site who strictly ONLY uses server side SSL (with client auth bein= g handled by passwords, etc.),=C2=A0 And, I have ability to turn of renego.= Will that do the trick? If so what portion of SSL users fall into this use= -case?



--
Ravi Ganesan
ravi@findravi.com
www.findravi.com
--0016e648f4b21d6704047ae0fa90-- From mrex@sap.com Wed Dec 16 16:29:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DC53A6AB8 for ; Wed, 16 Dec 2009 16:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 iXWas+eBN8fc for ; Wed, 16 Dec 2009 16:29: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 213313A6841 for ; Wed, 16 Dec 2009 16:29:11 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBH0Srbe001356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 01:28:53 +0100 (MET) From: Martin Rex Message-Id: <200912170028.nBH0Sqbt000958@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 17 Dec 2009 01:28:52 +0100 (MET) In-Reply-To: <4B296ABD.8050403@extendedsubset.com> from "Marsh Ray" at Dec 16, 9 05:18: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] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next 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, 17 Dec 2009 00:29:13 -0000 Marsh Ray wrote: > > > > I got confused. It is about early adopter clients that send > > TLS extension RI (not knowning about SCSV) and might run into > > updated servers that look only for SCSV. > > Such servers are not permitted by the current proposal. > > From http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt > > 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 (the previous > > client Finished.verify_data in the ClientHello and the concatenation > > of both Finished.verify_data values in the ServerHello). If the > > contents are incorrect, then it MUST generate a fatal > > "handshake_failure" alert and terminate the connection. > [...] > > TLS servers MUST support both the "renegotiation_info" extension and > > the TLS_RENEGO_PROTECTION_REQUEST SCSV. TLS servers which support You're quoting section 3 of the document. That part only applies to TLS peers implementing secure _renegotiation_. Section 4 seems to be incomplete, the last paragraph describes the situation only for non-renegotiating clients, the paragraph for non-renegotiating appears to be missing from section 4, but belongs there as well and with comparable characteristics than for non-renegotiating clients. > > > But as I described, > > these are going to be servers that do not renegotiate anyway, > > TLS does not define such a thing as a "server that does not > renegotiate". There may be in fact some application protocols or servers > which do not, but TLS provide no way to indicate this in the handshake. > > In practice, it requires deep code inspection to prove and many > application authors have been surprised to find out that their TLS > implementation will renegotiate for them automatically. An SSLv3 or TLS implementation will definitely not perform TLS renegotiation by accident or coincidence. It will require a few lines of code to enable that. What may happen, is that developers or maintainers who inherited code are not (or no longer) aware of the functionality being present. > > Therefore, it is impossible for a general-purpose client to know this > about any specific server. > > Therefore, it is a useless consideration for the protocol design. Huh? > > > so there even is _no_ security problem involved. > > An unpatched TLS connection can only be believed secure with code > inspection done on _both_ endpoints to prove that renegotiation can > never happen and/or application protocol analysis. Since a primary > feature of TLS is to support interoperability between diverse client and > server implementations, this is just not a common enough case to be > worth considering. Code inspection? That seems to be a fairly inefficient way. If you want to know whether it is there, try it. If you want to reliably disable it, it's <10 LoC. I'm sure the OpenSSL code maintainers didn't need a code inspection in order to find out which statements would be necessary to make sure the renegotiation will _not_ work. > > > So really, making up an argument against a mandatory SCSV > > is going to be tough. > > Not really. I'm all ears. Go ahead. -Martin From djhopwood@googlemail.com Wed Dec 16 19:11: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 798FE3A6868 for ; Wed, 16 Dec 2009 19:11: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=[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 L-t-liipmaLP for ; Wed, 16 Dec 2009 19:11:18 -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 9D99D3A6B2C for ; Wed, 16 Dec 2009 19:10:54 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so1313518eyf.5 for ; Wed, 16 Dec 2009 19:10:35 -0800 (PST) Received: by 10.213.25.79 with SMTP id y15mr7738332ebb.74.1261019434806; Wed, 16 Dec 2009 19:10:34 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 16sm967972ewy.6.2009.12.16.19.10.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Dec 2009 19:10:32 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B29A121.8060005@jacaranda.org> Date: Thu, 17 Dec 2009 03:10: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: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com> <20091216190811.71BF56C823C@kilo.networkresonance.com> In-Reply-To: <20091216190811.71BF56C823C@kilo.networkresonance.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5CA41497858694EC4E175E54" Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 03:11:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5CA41497858694EC4E175E54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > At Wed, 16 Dec 2009 10:53:37 +0100, > wrote: >> - The current draft doesn't clearly say what should be included in >> legacy (insecure) renegotiation ClientHellos. I am not sure if we have= >> enough clear opinions to call consensus, but keeping it aligned with >> the initial ClientHello (either MSCV or extension) seems to be one >> simple approach (but I hope to see the actual text). >=20 > Attached is some candidate text that attempts to implement this.=20 >=20 > It is possible that un-upgraded servers will request that the client > renegotiate. It is RECOMMENDED that clients refuse this > renegotiation request. Clients which do so MUST respond to such > requests with a "no_renegotiation" alert [RFC 5246 requires this > alert to be at the "warning" level.] It is possible that the > apparently un-upgraded server is in fact an attacker who is then > allowing the client to renegotiate with a different, legitimate, > upgraded server. In order to detect this attack, clients which > choose to renegotiate MUST provide either the > TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their > ClientHello. In a legitimate renegotiation with an un-upgraded > server, either of these signals will be ignored by the server. > However, if the server (incorrectly) fails to ignore extensions, > sending the "renegotiation_info" extension may cause a handshake > failure. Thus, it is permitted, though NOT RECOMMENDED, for the > client to simply send the SCSV. This is the only situation in which > clients are permitted to not send the "renegotiation_info" extension > in a ClientHello which is used for renegotiation. >=20 > Note that in the case of this downgrade attack attack above, if this > is the initial handshake from the server's perspective, then use of > the SCSV from the client precludes detection of this attack by the > server. That is not correct. If the server is also upgraded, it can detect that the SCSV has been sent without the extension on a renegotiating handshake= =2E This case must be an attack, because the client wouldn't have sent only the SCSV if it knew that the server was upgraded. (If the connection is a legitimate renegotiation and the server hasn't changed, the client would know that it is upgraded from the presence of the extension in the ServerHello of the previous handshake.) It is only un-upgraded servers that will not detect the attack (but the client accepted that possibility, contrary to the RECOMMENDATION in the second sentence of the above text). OTOH, I think it's perfectly reasonable not to allow clients to send only the SCSV on a renegotiation. As you say, > Sending RI in this instance only creates > an interop problem when a server (1) is doing something we know to be > really unsafe and (2) can't even ignore extensions correctly. Either way, the draft should specify that an upgraded server MUST abort a renegotiating handshake if it receives only SCSV without the extension.= --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig5CA41497858694EC4E175E54 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/ iF4EAREIAAYFAkspoScACgkQWUc8YzyzqAeeXAD/dRek/hA1wWxllvrCLo8j/zpI 6lQC3mvTJ+Qi08ckiKEBAJf5cjSnIcVPupB0Fc/4qAawurLb9yA0BK0fnJ+GSYsP =HV06 -----END PGP SIGNATURE----- --------------enig5CA41497858694EC4E175E54-- From djhopwood@googlemail.com Wed Dec 16 19:19: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 021C33A690F for ; Wed, 16 Dec 2009 19:19: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 IB7RxQe3pPJL for ; Wed, 16 Dec 2009 19:19:21 -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 875B03A68A6 for ; Wed, 16 Dec 2009 19:19:21 -0800 (PST) Received: by ewy6 with SMTP id 6so1749875ewy.29 for ; Wed, 16 Dec 2009 19:19: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=lY2Zhodr7UQ0LIBX86cfPj/VQ/ljul39+5V1sx+B0z8=; b=E4tnrB1TV4liT6wdD9FrYi8oVAPzBEXYAkC0TdqYX5qBFxJM7DUMiGlafBqi8UCmQv OdcxUfpNnCMpQV8lAVi9PXX8g/idgGssrJ6MNT6UIaJZlHqAOgF9iF/7fJ1dhQzBVAny coGcmjipDGgYi2e+ZRBNQrbPYzOikBcCTqP4Q= 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=bxDXbRNyQv1icgxUVKAefqd9+VHAW26eJhsl0LiHUVvWlPUTXaE7Z1QvIFQ6AIXcWG 7DPdQlITBA6V0GfgfXR5bHpJXUclQ52YJUldAPQyWh8OBrfaRKbLi8pGYRjogpPtMwbW CFQqgZOBvX9EjA4FeukH9rX2hfugvTjlnJlps= Received: by 10.213.103.9 with SMTP id i9mr2181660ebo.16.1261019941912; Wed, 16 Dec 2009 19:19:01 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 15sm972871ewy.12.2009.12.16.19.19.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Dec 2009 19:19:01 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B29A324.9080907@jacaranda.org> Date: Thu, 17 Dec 2009 03:19: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: <200912162032.nBGKWZwc016244@fs4113.wdf.sap.corp> In-Reply-To: <200912162032.nBGKWZwc016244@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFE909AED8A218491B889B506" Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 03:19:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFE909AED8A218491B889B506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > First, we need to fix the Definition of the TLS_RENEGO_PROTECTION_REQUE= ST: >=20 > This cipher suite value is the Client to Server signal that the client > is updated and asks to apply the strict rules of secure renegotiation > applied to the current handshake -- no excuses. >=20 > If SCSV is received by a server on an initial handshake that does > not contain a renegotiation_info TLS extension, then the server > should apply the same semantics as if it had received an empty > TLS extension RI in that ClientHello. >=20 > Concerning the question what a client should send on a backwards > interoperable renegotiation handshake: >=20 > The rule is "if you can't be good, at least be good at it.". >=20 > That means if the clients configuration permits old-style renegotiation= , > then he should NOT try fancy new tricks with that old server on the > renegotiation handshake that he didn't do on the initial handshake. >=20 > i.e. if the client had sent TLS extensions on the initial handshake, > there is no problem with _sending_ TLS extension RI on the renegotiatio= n > handshake with the old server. >=20 > However, if the client did _not_ use TLS extensions (but SCSV) on > the initial handshake with an old server, then there are only > to sensible options for the client on renegotiation: > (a) abort when the client doesn't allow old-style renegotiation > (b) send an extension-less ClientHello with [S]CSV on renegotiation. (b) is only secure if an upgraded server MUST abort if it receives an SCSV without an extension on a renegotiating handshake. I am *strongly* opposed to (b) without that requirement. With that requirement, I'm still weakly opposed to your argument here. Always sending the extension in a renegotiating ClientHello is much simpler. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFE909AED8A218491B889B506 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/ iF4EAREIAAYFAkspoyQACgkQWUc8YzyzqAd7MwEAnYPnS1s+0pfTv0E2uf7WM64l iFMBBmWbYIa0xGh4rBgBAIIfohkkwQril543mpZf3y3tIHSFmSqZG4cntz6uue6Y =2Dsv -----END PGP SIGNATURE----- --------------enigFE909AED8A218491B889B506-- From djhopwood@googlemail.com Wed Dec 16 19:25: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 7EAD93A6960 for ; Wed, 16 Dec 2009 19:25: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 rwIhCZSE140t for ; Wed, 16 Dec 2009 19:25:47 -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 E65F03A684D for ; Wed, 16 Dec 2009 19:25:46 -0800 (PST) Received: by ewy6 with SMTP id 6so1752878ewy.29 for ; Wed, 16 Dec 2009 19:25: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=2UWabg/QXumjM0F5ZE1UkPMPsOfFAVibCdnFwUPhhoo=; b=srGA5cNlaSvwvtOfH1EfXdBg6RhLOnSZl/Sq4+5B8mDUn05LRmVU44axmhklpEyyvj B8Cz0uWcMMCUd+P4XpLXRRCMt/qwPNE6rcoV1hazvZa04kAoazqc1A7/uoAu9kpnaGer P/ore7/CEPa03fsYBhkUDf4i+oHNiqCm9F/Es= 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=tPgF6IQ6jCQeEhcqhmFRuZTimkkYlkRJvsZCx8GN04aXwgYLE6oB8A73XOuNEF4rcX bE6455Uhh0SXQfswLjMScce5kpDcrhRwdI3njH1YVKLmpLWEpTAAPGCIyWhBqfPDYCQm rDIguE8JQ8KyYbjihaLb4sE5RMEMoH8pecBdE= Received: by 10.213.103.144 with SMTP id k16mr2088629ebo.66.1261020328883; Wed, 16 Dec 2009 19:25:28 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 14sm977345ewy.3.2009.12.16.19.25.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Dec 2009 19:25:27 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B29A4A4.1090106@jacaranda.org> Date: Thu, 17 Dec 2009 03:25: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: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> <4B296275.8010108@extendedsubset.com> In-Reply-To: <4B296275.8010108@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig84E5A475C3C56C1E0685D049" Subject: Re: [TLS] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 03:25:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig84E5A475C3C56C1E0685D049 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marsh Ray wrote: > Ravi Ganesan wrote: >> Anyone who reads the the first documents that came out on this issue >> (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and >> http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegot= i.html) >> would be left with very different perceptions of the magnitude of the >> impact. This is not unnatural in such matters; great minds usually thi= nk >> differently...., but after all this discussion perhaps a blurb in the >> draft with advice on who should immediately patch might be useful. >=20 > In short, everyone* needs to patch and disable compatible/insecure mode= > as soon as is practical. >=20 > *Except those who can prove that their endpoint cannot renegotiate and > will never be willing to talk to a server that can possibly renegotiate= =2E No, even those. If any server does not patch, it will soon fail to be interoperable with clients that require patched servers. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig84E5A475C3C56C1E0685D049 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/ iF4EAREIAAYFAksppKQACgkQWUc8YzyzqAeJlwD7BBHFdY2JQEdQrE+SUwRl3+1E wLKaMgo0Q4LtU9MfeikA/j7H3OvzlUuYcqXUC5HGBQmoKZrXkuImHLuXKBDalTr7 =hpRO -----END PGP SIGNATURE----- --------------enig84E5A475C3C56C1E0685D049-- From mrex@sap.com Wed Dec 16 19:39: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 E9BC63A6AA8 for ; Wed, 16 Dec 2009 19:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 xYj6C+54-5+L for ; Wed, 16 Dec 2009 19:39: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 CFE963A691E for ; Wed, 16 Dec 2009 19:39:37 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBH3dMNJ029656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 04:39:22 +0100 (MET) From: Martin Rex Message-Id: <200912170339.nBH3dLiI012743@fs4113.wdf.sap.corp> To: david-sarah@jacaranda.org (David-Sarah Hopwood) Date: Thu, 17 Dec 2009 04:39:21 +0100 (MET) In-Reply-To: <4B29A324.9080907@jacaranda.org> from "David-Sarah Hopwood" at Dec 17, 9 03:19:00 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-ietf-tls-renegotation: next steps 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, 17 Dec 2009 03:39:39 -0000 David-Sarah Hopwood wrote: > > Martin Rex wrote: > > First, we need to fix the Definition of the TLS_RENEGO_PROTECTION_REQUEST: > > > > This cipher suite value is the Client to Server signal that the client > > is updated and asks to apply the strict rules of secure renegotiation > > applied to the current handshake -- no excuses. > > > > If SCSV is received by a server on an initial handshake that does > > not contain a renegotiation_info TLS extension, then the server > > should apply the same semantics as if it had received an empty > > TLS extension RI in that ClientHello. > > > > Concerning the question what a client should send on a backwards > > interoperable renegotiation handshake: > > > > The rule is "if you can't be good, at least be good at it.". > > > > That means if the clients configuration permits old-style renegotiation, > > then he should NOT try fancy new tricks with that old server on the > > renegotiation handshake that he didn't do on the initial handshake. > > > > i.e. if the client had sent TLS extensions on the initial handshake, > > there is no problem with _sending_ TLS extension RI on the renegotiation > > handshake with the old server. > > > > However, if the client did _not_ use TLS extensions (but SCSV) on > > the initial handshake with an old server, then there are only > > to sensible options for the client on renegotiation: > > (a) abort when the client doesn't allow old-style renegotiation > > (b) send an extension-less ClientHello with [S]CSV on renegotiation. > > (b) is only secure if an upgraded server MUST abort if it receives an > SCSV without an extension on a renegotiating handshake. > I am *strongly* opposed to (b) without that requirement. That is what I tried to describe in the second sentence above of the mail that you quoted: "apply the strict rules of secure renegotiation to the current handshake -- no excuses". You're welcome to use more appropriate words to describe this. > > With that requirement, I'm still weakly opposed to your argument here. > Always sending the extension in a renegotiating ClientHello is much > simpler. That is one of the few useful conditionals, because it would be backwards-incompatible and unreasonable action to send an extension on a backwards-interop renegotiation scenario with an old(!) server if _NO_ extension was sent on the initial handshake. The spec should _not_ require implementers to offer this, and neither require apps to enable this, but _IF_ they offer it, then it just doesn't make sense to offer backwards interop renegotiation in an inconsistent fashion. -Martin From marsh@extendedsubset.com Wed Dec 16 21:13: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 D5D2E3A68F1 for ; Wed, 16 Dec 2009 21:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTOoga-4yR7X for ; Wed, 16 Dec 2009 21:13:29 -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 5B05E3A6924 for ; Wed, 16 Dec 2009 21:13: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 1NL8fp-0002xx-Si; Thu, 17 Dec 2009 05:13:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 313F86678; Thu, 17 Dec 2009 05:13: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: U2FsdGVkX1/8bbN1kU+QeT2DAqOOAq0pHlptgu1/dM4= Message-ID: <4B29BDE7.4020305@extendedsubset.com> Date: Wed, 16 Dec 2009 23:13:11 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David-Sarah Hopwood , "tls@ietf.org" References: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> <4B296275.8010108@extendedsubset.com> <4B29A4A4.1090106@jacaranda.org> In-Reply-To: <4B29A4A4.1090106@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] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 05:13:32 -0000 David-Sarah Hopwood wrote: > Marsh Ray wrote: >> In short, everyone* needs to patch and disable compatible/insecure mode >> as soon as is practical. >> >> *Except those who can prove that their endpoint cannot renegotiate and >> will never be willing to talk to a server that can possibly renegotiate. > > No, even those. > > If any server does not patch, it will soon fail to be interoperable with > clients that require patched servers. Good point. But they would not be insecure, just non-interoperable. Which is probably better than being insecure in the long run. So every interoperable system has just has to patch, which is basically all of them. It's simply not practical to offer guidelines for who doesn't need to patch. - Marsh From marsh@extendedsubset.com Wed Dec 16 22: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 6AD633A6B29 for ; Wed, 16 Dec 2009 22:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH-KQUyTYgZZ for ; Wed, 16 Dec 2009 22:10:46 -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 3436F3A6A1F for ; Wed, 16 Dec 2009 22:10: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 1NL9ZH-000Kmx-M7; Thu, 17 Dec 2009 06:10:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D5F8A6678; Thu, 17 Dec 2009 06:10: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: U2FsdGVkX18zgdIwqOHQj5Q8vaWP/TLb8X3eis/pZhk= Message-ID: <4B29CB55.4060306@extendedsubset.com> Date: Thu, 17 Dec 2009 00:10:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912170028.nBH0Sqbt000958@fs4113.wdf.sap.corp> In-Reply-To: <200912170028.nBH0Sqbt000958@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] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 06:10:59 -0000 Martin Rex wrote: > Marsh Ray wrote: >>> I got confused. It is about early adopter clients that send >>> TLS extension RI (not knowning about SCSV) and might run into >>> updated servers that look only for SCSV. >> Such servers are not permitted by the current proposal. >> >> From http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt >>> 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 (the previous >>> client Finished.verify_data in the ClientHello and the concatenation >>> of both Finished.verify_data values in the ServerHello). If the >>> contents are incorrect, then it MUST generate a fatal >>> "handshake_failure" alert and terminate the connection. >> [...] >>> TLS servers MUST support both the "renegotiation_info" extension and >>> the TLS_RENEGO_PROTECTION_REQUEST SCSV. TLS servers which support > > > You're quoting section 3 of the document. You mean the section "3. Extension Definition"? > That part only applies to TLS peers implementing secure _renegotiation_. Whatever gave you that idea? Obviously the part that says > If this is the initial handshake for a connection, then the > "renegotiated_connection" field is of zero length in both the > ClientHello and the ServerHello. is not limiting itself to renegotiations. I don't know how the IETF rules work, if a future implementaion can say it implements proper TLS without implementing this extension. In practice, every TLS implementation (except perhaps yours) is going to want to implement the security fix properly lest they be shunned by other implementations. > Section 4 seems to be incomplete, the last paragraph describes > the situation only for non-renegotiating clients, the paragraph > for non-renegotiating appears to be missing from section 4, For non-renegotiating what? There appears to be a word missing so your paragraph seems to be incomplete. > but belongs there as well and with comparable characteristics > than for non-renegotiating clients. You appear to be questioning why there isn't an equivalent statement about servers which do not renegotiate. If its absence is conspicuous and distracting to you, perhaps we should strike that whole last paragraph. It is redundant anyway. It's not an equivalent situation because the server must respond to the client hello as it was sent and can not "simply use the SCSV in all initial handshakes" like the client can. The logic for a non-renegotiating server does not reduce as much as it does for a non-renegotiating client. >> TLS does not define such a thing as a "server that does not >> renegotiate". There may be in fact some application protocols or servers >> which do not, but TLS provide no way to indicate this in the handshake. >> >> In practice, it requires deep code inspection to prove and many >> application authors have been surprised to find out that their TLS >> implementation will renegotiate for them automatically. > > An SSLv3 or TLS implementation will definitely not perform > TLS renegotiation by accident or coincidence. It will require > a few lines of code to enable that. Many applications have gotten renegotiation for free from their helpful TLS implementations with zero lines of added code. > What may happen, is that developers or maintainers who inherited > code are not (or no longer) aware of the functionality being present. Or even more likely, the application writers. >> Therefore, it is impossible for a general-purpose client to know this >> about any specific server. >> >> Therefore, it is a useless consideration for the protocol design. > > Huh? Yes. It is impossible for a TLS clients to know that they are talking to a server which can not be triggered to renegotiate in the general case, or even in most specific cases. >>> so there even is _no_ security problem involved. >> An unpatched TLS connection can only be believed secure with code >> inspection done on _both_ endpoints to prove that renegotiation can >> never happen and/or application protocol analysis. Since a primary >> feature of TLS is to support interoperability between diverse client and >> server implementations, this is just not a common enough case to be >> worth considering. > > Code inspection? That seems to be a fairly inefficient way. > > If you want to know whether it is there, try it. And you will conclude wrongly and it will result in a security vulnerability. Try doing a client-initiated renegotiation against MS IIS for example. It will hang up on you. Yet it's clear that a properly constructed HTTP request and the right server configuration will cause it to perform server-initiated renegotiation. Similarly, an https client may refuse requests for renegotiation unless he has a client certificate he's willing to offer to that specific server. There is absolutely no way for a server to determine whether this is the case or not with the client that's attempting to connect insecurely. It is very difficult to prove a negative. Security analyses based on "the remote endpoint does not renegotiate therefore our connection is not vulnerable" are betting they can prove that negative correctly every single time. My money is on the attacker who only needs to disprove it once. Again, the TLS protocol does not define such a thing as "TLS without renegotiation" and consequently there is no way for an endpoint to know that his remote peer can never be enticed into renegotiating. > If you want to reliably disable it, it's <10 LoC. http://cvs.openssl.org/timeline?d=5&e=2009-Nov-10&c=2&px=&s=1&dt=1&x=1&m=1&w=0 It was a little more than 10 LoC, but not a huge amount either. > I'm sure the OpenSSL code maintainers didn't need a code inspection > in order to find out which statements would be necessary to > make sure the renegotiation will _not_ work. I guess you've never looked at the OpenSSL codebase then. But I don't actually know of any codebase in which you can usefully change it without a little code inspection first. - Marsh From ravi@findravi.com Wed Dec 16 22:26: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 05C543A6B17 for ; Wed, 16 Dec 2009 22:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UQ7GTrhTf3ga for ; Wed, 16 Dec 2009 22:26:24 -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 81CF63A6A62 for ; Wed, 16 Dec 2009 22:26:24 -0800 (PST) Received: by pwi20 with SMTP id 20so1223241pwi.29 for ; Wed, 16 Dec 2009 22:26:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.5.26 with SMTP id 26mr1399291wae.214.1261031167643; Wed, 16 Dec 2009 22:26:07 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2009 22:26:07 -0800 Message-ID: <3561bdcc0912162226p1994c9eeqc7fbc192cab811a1@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e64beaeecc6afe047ae6b25c Subject: Re: [TLS] TLS Digest, Vol 65, Issue 69 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 06:26:27 -0000 --0016e64beaeecc6afe047ae6b25c Content-Type: text/plain; charset=UTF-8 > > Ravi Ganesan wrote: > >> Anyone who reads the the first documents that came out on this issue > >> (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and > >> > http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html > ) > >> would be left with very different perceptions of the magnitude of the > >> impact. This is not unnatural in such matters; great minds usually think > >> differently...., but after all this discussion perhaps a blurb in the > >> draft with advice on who should immediately patch might be useful. > > > > In short, everyone* needs to patch and disable compatible/insecure mode > > as soon as is practical. > > > > *Except those who can prove that their endpoint cannot renegotiate and > > will never be willing to talk to a server that can possibly renegotiate. > > No, even those. > > If any server does not patch, it will soon fail to be interoperable with > clients that require patched servers. > I see. Sorry, I missed that in all the discussion. Sticking to the specific case of when the Client is a browser and the Server is a web-server do the browser vendors plan to "require" patched servers? I was assuming (hoping?) that a patched browser can deal with an unpatched server gracefully without failing. I have selfish reasons for asking as I run a EV-SSL protected site, with no control over when my hosting company will upgrade, but I suspect this would be the single most impacted use case. Cheers, Ravi -- Ravi Ganesan ravi@findravi.com www.findravi.com --0016e64beaeecc6afe047ae6b25c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Ravi Ganesan wrote:
>> Anyone who reads the =C2=A0the first documents that came out on th= is issue
>> (http://www.phonefactor.com/sslgapdocs/Renegotiatin= g_TLS.pdf and
>> http://www.educatedguesswork.org/2= 009/11/understanding_the_tls_renegoti.html)
>> would be left with very different perceptions of the magnitude of = the
>> impact. This is not unnatural in such matters; great minds usually= think
>> differently...., but after all this discussion perhaps a blurb in = the
>> draft with advice on who should immediately patch might be useful.=
>
> In short, everyone* needs to patch and disable compatible/insecure mod= e
> as soon as is practical.
>
> *Except those who can prove that their endpoint cannot renegotiate and=
> will never be willing to talk to a server that can possibly renegotiat= e.

No, even those.

If any server does not patch, it will soon fail to be interoperable with clients that require patched servers.
<= br>I see. Sorry, I missed that in all the discussion. Sticking to the speci= fic case of when the Client is a browser and the Server is a web-server do = the browser vendors plan to "require" patched servers?=C2=A0 I wa= s assuming (hoping?) that a patched browser can deal with an unpatched serv= er gracefully without failing. I have selfish reasons for asking as I run a= EV-SSL protected site, with no control over when my hosting company will u= pgrade, but I suspect this would be the single most impacted use case. Chee= rs, Ravi


--
Ravi Ganesan
ravi@fi= ndravi.com
www.findravi.com<= br> --0016e64beaeecc6afe047ae6b25c-- From ynir@checkpoint.com Wed Dec 16 22: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 C70E13A6817 for ; Wed, 16 Dec 2009 22:58:36 -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=[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 79P9-K49UO-l for ; Wed, 16 Dec 2009 22:58:35 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5C54F3A67B8 for ; Wed, 16 Dec 2009 22:58:35 -0800 (PST) X-CheckPoint: {4B29D5AC-10002-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7FBE429C005; Thu, 17 Dec 2009 08:58:19 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 691D729C002; Thu, 17 Dec 2009 08:58:19 +0200 (IST) X-CheckPoint: {4B29D5AB-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBH6wJT7009453; Thu, 17 Dec 2009 08:58:19 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 17 Dec 2009 08:58:29 +0200 From: Yoav Nir To: Ravi Ganesan Date: Thu, 17 Dec 2009 08:58:15 +0200 Thread-Topic: [TLS] Third Option? Thread-Index: Acp+5lZpzUoC643sSfKABcoBh2+nZA== Message-ID: References: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> <4B296275.8010108@extendedsubset.com> <3561bdcc0912161509j799392d1t2f4f09a7d1184737@mail.gmail.com> <3561bdcc0912161536y5e240e6cqe414c7d4aa2baef8@mail.gmail.com> In-Reply-To: <3561bdcc0912161536y5e240e6cqe414c7d4aa2baef8@mail.gmail.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_A7CF2975946244CD80E588E5AC4071C2checkpointcom_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 06:58:36 -0000 --_000_A7CF2975946244CD80E588E5AC4071C2checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 17, 2009, at 1:36 AM, Ravi Ganesan wrote: On Wed, Dec 16, 2009 at 2:43 PM, Marsh Ray > wrote: Ravi Ganesan wrote: > > A third option is to leave renegotiation in, but create an advisory that > explains the semantics; What do you (as a vendor) tell your customers when they know they are vulnerable and call you for a fix? Have TLS 1.3 code ready and tell them to upgrade to it. Asking customers t= o move to newer release in order to fix security problems is something the = market understands. (did not say 'likes'). Except that the browsers they have don't support TLS 1.3 yet. If the TLS 1.= 3 spec came out today, it would be years (8? 10?) before you can assume tha= t everyone has a supporting browser. However, if you are correct in your impact analysis in your original paper,= then an emergency patch is the appropriate response. I am not sure I know = enough to agree with your impact analysis, but either way, good job done by= your team and Martin on this discovery -- it will make TLS 1.3 better. One stat that might allow us to ascertain immediate impact: If I am a web = site who strictly ONLY uses server side SSL (with client auth being handled= by passwords, etc.), And, I have ability to turn of renego. Will that do = the trick? If so what portion of SSL users fall into this use-case? Yes. Disabling renegotiation on the server side solves the problem, and pro= bably over 95% of users fall into this use case. However, even for them, t= here are two problems with this solution: - until very recently there was no "disable renegotiation" switch on the v= arious servers. OpenSSL added this to 0.9.8l just last month. Upgrading to= OpenSSL 0.9.8l means getting all the code changes between the release you'= re using and the new OpenSSL version. This might cause you other problems. - There's no signaling that renegotiations are disabled. The browser cannot= show me that I'm talking to a secured server. --_000_A7CF2975946244CD80E588E5AC4071C2checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Dec 17, 2= 009, at 1:36 AM, Ravi Ganesan wrote:

On Wed, Dec 16, 2009 at 2:43 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
Ravi Ganesan wrote:
>
> A third option is to leave renegotiation in, but create an advisory th= at
> explains the semantics;

What do you (as a vendor) tell your customers when they know they are=
vulnerable and call you for a fix?


Have TLS 1.3 code ready and tell= them to upgrade to it.  Asking customers to move to newer release in = order to fix security problems is something the market understands. (did no= t say 'likes').

Excep= t that the browsers they have don't support TLS 1.3 yet. If the TLS 1.3 spe= c came out today, it would be years (8? 10?) before you can assume that eve= ryone has a supporting browser.


However, if you are correct in your impact analysis in your original pa= per, then an emergency patch is the appropriate response. I am not sure I k= now enough to agree with your impact analysis, but either way, good job don= e by your team and Martin on this discovery -- it will make TLS 1.3 better.=

One stat that might allow us  to ascertain immediate impact: If I = am a web site who strictly ONLY uses server side SSL (with client auth bein= g handled by passwords, etc.),  And, I have ability to turn of renego.= Will that do the trick? If so what portion of SSL users fall into this use= -case?

Yes. Disabling rene= gotiation on the server side solves the problem, and probably over 95% of u= sers fall into this use case.  However, even for them, there are two p= roblems with this solution:
 - until very recently there was= no "disable renegotiation" switch on the various servers.  OpenSSL ad= ded this to 0.9.8l just last month. Upgrading to OpenSSL 0.9.8l means getti= ng all the code changes between the release you're using and the new OpenSS= L version. This might cause you other problems.
- There's no signaling that renegotiations ar= e disabled. The browser cannot show me that I'm talking to a secured server= .


= --_000_A7CF2975946244CD80E588E5AC4071C2checkpointcom_-- From ynir@checkpoint.com Wed Dec 16 23:04: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 316A03A6B17 for ; Wed, 16 Dec 2009 23:04:56 -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=[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 sKQ57DDXdvvo for ; Wed, 16 Dec 2009 23:04:55 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0E1203A67B8 for ; Wed, 16 Dec 2009 23:04:54 -0800 (PST) X-CheckPoint: {4B29D727-10005-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8E3E029C008; Thu, 17 Dec 2009 09:04:39 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7359729C002; Thu, 17 Dec 2009 09:04:39 +0200 (IST) X-CheckPoint: {4B29D727-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBH74dT7010096; Thu, 17 Dec 2009 09:04:39 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 17 Dec 2009 09:04:50 +0200 From: Yoav Nir To: Ravi Ganesan Date: Thu, 17 Dec 2009 09:04:36 +0200 Thread-Topic: [TLS] TLS Digest, Vol 65, Issue 69 Thread-Index: Acp+5zlZh0CNr+0jRsqUqQCGv5qj6A== Message-ID: References: <3561bdcc0912162226p1994c9eeqc7fbc192cab811a1@mail.gmail.com> In-Reply-To: <3561bdcc0912162226p1994c9eeqc7fbc192cab811a1@mail.gmail.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_DF4882FB9EEC4725A737AB332530A97Fcheckpointcom_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Digest, Vol 65, Issue 69 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 07:04:56 -0000 --_000_DF4882FB9EEC4725A737AB332530A97Fcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 17, 2009, at 8:26 AM, Ravi Ganesan wrote: > Ravi Ganesan wrote: >> Anyone who reads the the first documents that came out on this issue >> (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and >> http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.= html) >> would be left with very different perceptions of the magnitude of the >> impact. This is not unnatural in such matters; great minds usually think >> differently...., but after all this discussion perhaps a blurb in the >> draft with advice on who should immediately patch might be useful. > > In short, everyone* needs to patch and disable compatible/insecure mode > as soon as is practical. > > *Except those who can prove that their endpoint cannot renegotiate and > will never be willing to talk to a server that can possibly renegotiate. No, even those. If any server does not patch, it will soon fail to be interoperable with clients that require patched servers. I see. Sorry, I missed that in all the discussion. Sticking to the specific= case of when the Client is a browser and the Server is a web-server do the= browser vendors plan to "require" patched servers? "require"? My bet is, not anytime soon. I was assuming (hoping?) that a patched browser can deal with an unpatched = server gracefully without failing. I have selfish reasons for asking as I r= un a EV-SSL protected site, with no control over when my hosting company wi= ll upgrade, but I suspect this would be the single most impacted use case. = Cheers, Ravi My guess is that when patched servers have become common enough that it's w= eird to have an unpatched server, browser vendors will make us go through t= he "Continue to this website (not recommended)"/"I understand the risks"/"S= afari can't verify..."/"You need to approve or reject" ritual that they mak= e us go through for certificate errors. --_000_DF4882FB9EEC4725A737AB332530A97Fcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Dec 17, 2= 009, at 8:26 AM, Ravi Ganesan wrote:


> Ravi Ganesan wrote:
>> Anyone who reads the  the first documents that came out on th= is issue
>> (http://www.phonefactor.com/sslgapdocs/Renegotiatin= g_TLS.pdf and
>> http://www.educatedguesswork.org/2= 009/11/understanding_the_tls_renegoti.html)
>> would be left with very different perceptions of the magnitude of = the
>> impact. This is not unnatural in such matters; great minds usually= think
>> differently...., but after all this discussion perhaps a blurb in = the
>> draft with advice on who should immediately patch might be useful.=
>
> In short, everyone* needs to patch and disable compatible/insecure mod= e
> as soon as is practical.
>
> *Except those who can prove that their endpoint cannot renegotiate and=
> will never be willing to talk to a server that can possibly renegotiat= e.

No, even those.

If any server does not patch, it will soon fail to be interoperable with clients that require patched servers.
<= br>I see. Sorry, I missed that in all the discussion. Sticking to the speci= fic case of when the Client is a browser and the Server is a web-server do = the browser vendors plan to "require" patched servers? 
"require"? My bet is, not anytime soon.

I was assuming (hoping?) that a patched browser can deal= with an unpatched server gracefully without failing. I have selfish reason= s for asking as I run a EV-SSL protected site, with no control over when my= hosting company will upgrade, but I suspect this would be the single most = impacted use case. Cheers, Ravi

My guess is = that when patched servers have become common enough that it's weird to have= an unpatched server, browser vendors will make us go through the "Continue= to this website (not recommended)"/"I understand the risks"/"Safari can't = verify..."/"You need to approve or reject" ritual that they make us go thro= ugh for certificate errors. 

= --_000_DF4882FB9EEC4725A737AB332530A97Fcheckpointcom_-- From Pasi.Eronen@nokia.com Thu Dec 17 03: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 7B3AE3A69D6 for ; Thu, 17 Dec 2009 03:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 i2QJXIvW0vq0 for ; Thu, 17 Dec 2009 03:31:26 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 544D53A6997 for ; Thu, 17 Dec 2009 03:31:26 -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 nBHBUeda006822; Thu, 17 Dec 2009 13:31:07 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 13:30:56 +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, 17 Dec 2009 13:30:51 +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; Thu, 17 Dec 2009 12:30:51 +0100 From: To: Date: Thu, 17 Dec 2009 12:30:49 +0100 Thread-Topic: [TLS] Re: draft-ietf-tls-renegotation: next Thread-Index: Acp+kqHpKubfQdWgTq+wOKrcQt/lcAAd93uw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com> References: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> from "Kemp, David P." at Dec 16, 9 03:00:39 pm <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> In-Reply-To: <200912162059.nBGKx7Sv017923@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: 17 Dec 2009 11:30:51.0942 (UTC) FILETIME=[63842460:01CA7F0C] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 11:31:27 -0000 Martin Rex worte: > I do not fully agree with the AD's determination of rough consensus. >=20 > For the MCSV signaling, the real rough consensus is different from > what Pasi wrote: >=20 > http://www.ietf.org/mail-archive/web/tls/current/msg05306.html >=20 > A mandatory Client->Server signaling through cipher suite may > have less fanatic followers by the count of numbers, but technical > advantages and _no_ technical objections have been raised against it. Several people have very clearly and strongly objected to making the MSCV mandatory-to-include in ClientHello. You seem to be suggesting that their opinions don't somehow matter because they are, in *your* opinion, not "technical". > The current either cipher suite or empty TLS extension RI signaling > may have more "pro", but has significant objections against it > because of the ambiguity, increased complexity, a 4x code size > burden for old non-rengotiating servers and additional testing > complexity. If the specification text is ambiguous, we obviously need to fix that. About the code/testing complexity/effort: I would say most people believe that no matter what details get selected, this is not a significant amount of work (so small differences in lines of code or test cases should not signify much in making the decision). > So as far as rough consensus is concerned, it is definitely with the > approach I described. =20 I disagree. Best regards, Pasi (wearing Security Area Director hat) From mrex@sap.com Thu Dec 17 07: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 C0B5428C123 for ; Thu, 17 Dec 2009 07:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 XmhCSFo6Wdpw for ; Thu, 17 Dec 2009 07:23: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 E01343A6801 for ; Thu, 17 Dec 2009 07:23:41 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBHFNOs2019323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 16:23:24 +0100 (MET) From: Martin Rex Message-Id: <200912171523.nBHFNOMU024985@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 17 Dec 2009 16:23:24 +0100 (MET) In-Reply-To: <4B29CB55.4060306@extendedsubset.com> from "Marsh Ray" at Dec 17, 9 00:10: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] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next 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, 17 Dec 2009 15:23:43 -0000 Marsh Ray wrote: > > Obviously the part that says > > If this is the initial handshake for a connection, then the > > "renegotiated_connection" field is of zero length in both the > > ClientHello and the ServerHello. > is not limiting itself to renegotiations. > > I don't know how the IETF rules work, if a future implementaion can say > it implements proper TLS without implementing this extension. In > practice, every TLS implementation (except perhaps yours) is going to > want to implement the security fix properly lest they be shunned by > other implementations. I'm not an IETF process wizard. but I have not knowingly come across such a situation with IETF protocols so far. There will likely not be TLSv1.0-2010, TLSv1.1-2010 and TLSv1.2-2010. There will be implementations of particular RFCs, but if an implementation says TLSv1.0, that will not _by_itself_ imply that this includes any updates. You will probably need to look for the update-RFC number to be explicitly mentioned. The point in time when a product is developed or shipped or sold does not impact this at all. > > > Section 4 seems to be incomplete, the last paragraph describes > > the situation only for non-renegotiating clients, the paragraph > > for non-renegotiating servers appears to be missing from section 4, > > but belongs there as well and with comparable characteristics > > than for non-renegotiating clients. > > You appear to be questioning why there isn't an equivalent statement > about servers which do not renegotiate. Correct. The absence of that makes that update unnecessary complex. Myself, I don't have any of the gadgets like these: http://www.networkwebcams.co.uk/product_info.php?products_id=855 which implement SSL. I don't know whether they desperately need renegotiation, but I woul not discount the possibility that they do not need it. I don't know how many years manufacturers provide firmware updates for such gadgets, and how difficult it is to update them. But if such a thing doesn't need renegotiation, then it might make a difference for the decision for a manufacturer whether to develop a firmware update for a 3+ year old product, whether there's a simple "I'm updated" signaling available. I guess we will get accustomed to using several browsers in a year in order to not have to unnecessarily dump a lot of equiment that isn't really defective, but no longer interoperable with browsers from some suppliers. Those weenies in the IETF that ask for interoperability in communication protocols do not have a clue about communication _and_ security, and do not understand how important it is that you Javascript- and ActiveContent-enabled Browser no longer talks to this dangerous WebCam and all those other boxes and gadgets that you bought more than two years ago. > > It's not an equivalent situation because the server must respond to the > client hello as it was sent and can not "simply use the SCSV in all > initial handshakes" like the client can. The logic for a > non-renegotiating server does not reduce as much as it does for a > non-renegotiating client. Well, it _could_ be like that, as demonstrated by my specification. > > >> TLS does not define such a thing as a "server that does not > >> renegotiate". There are a number of things that TLS fails to define -- which is exactly the reason why the TLS renegotiation vulnerability went unnoticed for so long. My copy of rfc-5246 clearly describes that there are non-renegotiating clients and servers: rfc5246, Appendix D D.4. Implementation Pitfalls Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand, and have been a source of interoperability and security problems. TLS protocol issues: - Do you support renegotiation, both client and server initiated? While renegotiation is an optional feature, supporting it is highly recommended. > > >> Therefore, it is impossible for a general-purpose client to know this > >> about any specific server. > >> > >> Therefore, it is a useless consideration for the protocol design. > > > > Huh? > > Yes. It is impossible for a TLS clients to know that they are talking to > a server which can not be triggered to renegotiate in the general case, > or even in most specific cases. So what? Do you think that dropping from HTTPS as it is today to HTTP will be an improvement to the overall security of the internet, because you _are_, in fact, suggesting this? > > > If you want to reliably disable it, it's <10 LoC. > > http://cvs.openssl.org/timeline?d=5&e=2009-Nov-10&c=2&px=&s=1&dt=1&x=1&m=1&w=0 > > It was a little more than 10 LoC, but not a huge amount either. As I previously mentioned, the "official" patch that is currently in openssl-0.9.8l seems a little rough, because it will freeze the handshake when the client sends a ClientHello on an established TLS session. The patch that I would use to reliably abort a renegotiation handshake would be something like s3_srvr.c: case SSL3_ST_SR_CLNT_HELLO_C: + if (NULL != s->enc_read_ctx) + { + SSLerr( /* some adequate error code */ ); + s3_send_alert(s,SSL_AL_FATAL,SSL_AD_HANDSHAKE_FAILURE); + return(-1); + } ... ssl3_get_client_hello(s,...) > > > I'm sure the OpenSSL code maintainers didn't need a code inspection > > in order to find out which statements would be necessary to > > make sure the renegotiation will _not_ work. > > I guess you've never looked at the OpenSSL codebase then. But I don't > actually know of any codebase in which you can usefully change it > without a little code inspection first. No, I didn't. That diff I posted which implements my specification is only a wild guess an works by pure chance, just like a lot of those TLS protocol implementations that you know perform renegotiation without their original _implementors_ being aware of it. -Martin From mrex@sap.com Thu Dec 17 08: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 B1A6A3A68B4 for ; Thu, 17 Dec 2009 08:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 TPpHEamr9ZFF for ; Thu, 17 Dec 2009 08:02: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 9E0023A63EB for ; Thu, 17 Dec 2009 08:02:04 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBHG1fSp007785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 17:01:41 +0100 (MET) From: Martin Rex Message-Id: <200912171601.nBHG1ef5027443@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Thu, 17 Dec 2009 17:01:40 +0100 (MET) In-Reply-To: from "Yoav Nir" at Dec 17, 9 08:58:15 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: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Third Option? 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, 17 Dec 2009 16:02:05 -0000 Yoav Nir wrote: > > What do you (as a vendor) tell your customers when they know they are > vulnerable and call you for a fix? > > Have TLS 1.3 code ready and tell them to upgrade to it. Asking customers > to move to newer release in order to fix security problems is something > the market understands. (did not say 'likes'). I haven't seen a market that understand this. Vendors have been shipping very annoying auto-update functionality in order to get at least a part of the installed base to upgrade. Outside of the commodity market, you may get to see some customer's lawyers if you suggest "moving to a newer release" instead of providing a patch to defects in your products. > - There's no signaling that renegotiations are disabled. > The browser cannot show me that I'm talking to a secured server. Yes, I feel so much safer when I know that I'm talking to an TLS-updated rogue server. The difference this update will make is much smaller as some try to make you believe. It is definitely not like you are competely and hopelessly insecure without it, and top-notch invincible as soon as you deploy it. The endpoint identifications used by application protocols on top of TLS contains plenty of weaknesses itself. So it's not like you should stop worrying. It's just that your focus shifts and you have to worry more about other things now, some of which may me much harder to fix. -Martin From mrex@sap.com Thu Dec 17 09:36: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 C77213A68B4 for ; Thu, 17 Dec 2009 09:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 HmJgBJp1OR3C for ; Thu, 17 Dec 2009 09:36: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 9FE1A3A68A2 for ; Thu, 17 Dec 2009 09:36:22 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBHHa1e1026333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 18:36:01 +0100 (MET) From: Martin Rex Message-Id: <200912171735.nBHHZxLk003093@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 17 Dec 2009 18:35:59 +0100 (MET) In-Reply-To: <200912171523.nBHFNOMU024985@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 17, 9 04:23: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] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next 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, 17 Dec 2009 17:36:24 -0000 Martin Rex wrote: > > Marsh Ray wrote: > > > > Obviously the part that says > > > If this is the initial handshake for a connection, then the > > > "renegotiated_connection" field is of zero length in both the > > > ClientHello and the ServerHello. > > is not limiting itself to renegotiations. > > > > I don't know how the IETF rules work, if a future implementaion can say > > it implements proper TLS without implementing this extension. In > > practice, every TLS implementation (except perhaps yours) is going to > > want to implement the security fix properly lest they be shunned by > > other implementations. > > I'm not an IETF process wizard. but I have not knowingly come > across such a situation with IETF protocols so far. > > There will likely not be TLSv1.0-2010, TLSv1.1-2010 and TLSv1.2-2010. > > There will be implementations of particular RFCs, but if an > implementation says TLSv1.0, that will not _by_itself_ imply > that this includes any updates. You will probably need to look > for the update-RFC number to be explicitly mentioned. > > The point in time when a product is developed or shipped or sold > does not impact this at all. Btw. if your product implements TLSv1.0+TLSextensionRI and completely fails to interoperate with compliant implementations of TLSv1.0 without that update, then _YOUR_ product will be TLSv1.0-incompliant -- there is no doubt about that! Any kind of suggestion in the specification that updated client and servers should completely fail interoperation with compliant implementations without that update (i.e. also initial handshakes) is a bad idea, and I explicitly object to that. A specification with such a suggestion is _NOT_ an update to the existing specs, it is an entirely new, non-interoperable protocol! Offering applications or consumers configuration options so that they can obtain this result is slightly different. But as soon as you strongly suggest to kill the entire interoperability or configure it that way by default, you no longer have an implementation compliant to the original protocol. -Martin From mike-list@pobox.com Thu Dec 17 10:08: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 AA27B3A696B for ; Thu, 17 Dec 2009 10:08:05 -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 N3uJd46Udgbv for ; Thu, 17 Dec 2009 10:08:04 -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 97EA83A680F for ; Thu, 17 Dec 2009 10:08: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 8A789890D0 for ; Thu, 17 Dec 2009 13:07: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=7oC0nRSTZoyv VIZ1UKgKA2zqt2w=; b=DBwl+bX/dvNIJAJxzz2iCl/u8CRw219LuIzQudZjutcI yTbyZSKZgB7UJ0f8wQHXBhnJFfgUCM008FNDOEXy8fS8e8D80N9ty9IQPOglMsly wZz0GWSr6VTNgPfR4/UM6WIUgt/KkzYVk3YN92Fq+Kf5DnwxlR1SUQQdaS7PivE= 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=ZuciBs 9GmGJqkDdOJTe/AVa/34wUu6+0adtlCoaCzWk6Yw+Yp5tAjSDBoxg7Fo14onAHhg x0aRCL3ccB2jKO0P/Gt34PaW6XoxKt8OAoB5xnRyw4gg7ZJIuAqWT/dN08eyssbE 5ZS+YmexsCO8xGcVQK9jkCfUqTRadId/baf5E= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8582D890CF for ; Thu, 17 Dec 2009 13:07: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 89E1D890CE for ; Thu, 17 Dec 2009 13:07:48 -0500 (EST) Message-ID: <4B2A73C7.7030505@pobox.com> Date: Thu, 17 Dec 2009 10:09:11 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Mailing List References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> In-Reply-To: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 16201782-EB37-11DE-BDF4-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Updated 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, 17 Dec 2009 18:08:05 -0000 s/signalling/signaling/g In section 4 it says: Because the SCSV is equivalent to an empty "renegotiation_info" extension, any ClientHello used for secure renegotiation MUST include the "renegotiation_info" extension and not the SCSV. I would rather see the text say that "an RI extension takes precedence over the SCSV" than to say that you must not send SCSV when you send RI. It is easier for a client to simply include SCSV in every ClientHello. It is also trivial for a server to handle this, as I pointed out in my last message. Mike Eric Rescorla wrote: > I've just submitted a new draft that is intended to enact most of > Pasi's message as well as the noncontroversial editorial comments > people have raised. Here is what I know still needs work: > > - The final resolution to what's sent in the legacy renegotiation > case (see Pasi's message and the text I sent earlier). > - New text for the identity section in Security considerations. > (Pending closure on the list). > - Make a pass through for clarity for implementors. > (Also, I have some text here that Pasi contributed that I > need to work in). > > If you think you made a comment which is noncontroversial > that didn't make it in and/or I screwed up incorporating your > comment, please let me know and I'll try to fix. > > For some reason, the submission tool is forcing manual > submission. In the interim you can find it at: > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate.txt > > Thanks, > -Ekr From mrex@sap.com Thu Dec 17 10: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 4E9283A694D for ; Thu, 17 Dec 2009 10:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 MjM9m1dNg4Pf for ; Thu, 17 Dec 2009 10:58: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 469E13A69C1 for ; Thu, 17 Dec 2009 10:58:34 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBHIwHjw029872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 19:58:17 +0100 (MET) From: Martin Rex Message-Id: <200912171858.nBHIwG5H008367@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 17 Dec 2009 19:58:16 +0100 (MET) In-Reply-To: <4B296ABD.8050403@extendedsubset.com> from "Marsh Ray" at Dec 16, 9 05:18: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-ietf-tls-renegotation: next 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, 17 Dec 2009 18:58:35 -0000 Marsh Ray wrote: > > > But as I described, > > these are going to be servers that do not renegotiate anyway, > > TLS does not define such a thing as a "server that does not > renegotiate". There may be in fact some application protocols or servers > which do not, but TLS provide no way to indicate this in the handshake. As evident from rfc-5246 Appendix D. renegotiation is an optional feature of the SSLv3/TLS protocol family and not available in all implementations of SSLv3/TLS. Since you are still listed as an author of the spec, I consider your interpretation fairly authoritative for what the spec intends to say. --which means that there is a defect, because it does currently _not_ specify the behaviour for non-renegotiating servers (which you incorrectly assumed to not exist). Please fix this defect _before_ publishing this specification. The only reason why secure TLS renegotiation can be considered an update to the existing installed base at all (and not a different non-interoperable protocol), is that renegotiation has never been a core element of SSLv3/TLS and is optional-to-implement. Essentially, the secure renegotiation spec is deprecating the old renegotiation and defining a new, optional, secure renegotiation. Describing potential vulnerabilities from using backwards-interoble renegotiation with the installed base and discouraging the use of that old optional feature is fine. Encouraging the use the new optional and secure renegotiation is also no problem. Describing security implications of old TLS peers that still offer old renegotiation is also no problem. Discouraging the interoperability with compliant but not updated SSLv3->TLSv1.2 on the core protocol elements (aka initial TLS handshake) is inacceptable, because it would make updated TLS peers non-compliant with the original TLS spec, which implies these peers are using a different protocol. -Martin From stefan@aaa-sec.com Thu Dec 17 11:12: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 D4B203A6980 for ; Thu, 17 Dec 2009 11:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 WnhuOhKtZ-sa for ; Thu, 17 Dec 2009 11:12:17 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 500C53A6886 for ; Thu, 17 Dec 2009 11:12:16 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 99CCA2E27E9 for ; Thu, 17 Dec 2009 20:06:30 +0100 (CET) Received: (qmail 87648 invoked from network); 17 Dec 2009 19:06:23 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO MacBookPro-6.local) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 17 Dec 2009 19:06:23 -0000 Received: from [127.0.0.1] by MacBookPro-6.local (PGP Universal service); Thu, 17 Dec 2009 20:06:23 +0100 X-PGP-Universal: processed; by MacBookPro-6.local on Thu, 17 Dec 2009 20:06:23 +0100 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 17 Dec 2009 20:06:17 +0100 From: Stefan Santesson To: , Yoav Nir Message-ID: Thread-Topic: [TLS] Third Option? Thread-Index: Acp/TAKFA5EgvZEggUKxzinghX1zsw== In-Reply-To: <200912171601.nBHG1ef5027443@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 19:12:19 -0000 Just to clarify my own position on this. I believe we should fix this issue and I would personally favor the mrex draft approach as it provides better security properties, is cleaner and more generic. However, if the consensus for some reason would be to NOT provide a fix, then I think it would be better to just clarify the security properties of current renegotiation rather than attempting to ban it. /Stefan On 09-12-17 5:01 PM, "Martin Rex" wrote: > Yoav Nir wrote: >> >> What do you (as a vendor) tell your customers when they know they are >> vulnerable and call you for a fix? >> >> Have TLS 1.3 code ready and tell them to upgrade to it. Asking customers >> to move to newer release in order to fix security problems is something >> the market understands. (did not say 'likes'). > > I haven't seen a market that understand this. > Vendors have been shipping very annoying auto-update functionality > in order to get at least a part of the installed base to upgrade. > > Outside of the commodity market, you may get to see some customer's > lawyers if you suggest "moving to a newer release" instead of providing > a patch to defects in your products. > > >> - There's no signaling that renegotiations are disabled. >> The browser cannot show me that I'm talking to a secured server. > > Yes, I feel so much safer when I know that I'm talking to an TLS-updated > rogue server. The difference this update will make is much smaller > as some try to make you believe. It is definitely not like you > are competely and hopelessly insecure without it, and > top-notch invincible as soon as you deploy it. > > The endpoint identifications used by application protocols on top of > TLS contains plenty of weaknesses itself. So it's not like you > should stop worrying. It's just that your focus shifts and you > have to worry more about other things now, some of which may me > much harder to fix. > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mrex@sap.com Thu Dec 17 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 C1C203A677C for ; Thu, 17 Dec 2009 12:22:22 -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 BVTM+7R3Qmbx for ; Thu, 17 Dec 2009 12:22: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 D3E683A689B for ; Thu, 17 Dec 2009 12:22:17 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBHKM2NS006588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 21:22:02 +0100 (MET) From: Martin Rex Message-Id: <200912172022.nBHKM0Sx013218@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Thu, 17 Dec 2009 21:22:00 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 17, 9 12:30:49 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-ietf-tls-renegotation: next 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, 17 Dec 2009 20:22:23 -0000 Pasi.Eronen@nokia.com wrote: > > Martin Rex worte: > > > I do not fully agree with the AD's determination of rough consensus. > > > > For the MCSV signaling, the real rough consensus is different from > > what Pasi wrote: > > > > http://www.ietf.org/mail-archive/web/tls/current/msg05306.html > > > > A mandatory Client->Server signaling through cipher suite may > > have less fanatic followers by the count of numbers, but technical > > advantages and _no_ technical objections have been raised against it. > > Several people have very clearly and strongly objected to making the > MSCV mandatory-to-include in ClientHello. You seem to be suggesting > that their opinions don't somehow matter because they are, in *your* > opinion, not "technical". Well, I'm sorry, but it seems that I have totally forgotten the technical arguments they were making, and I seem to be unable to find it in my Email. Since you just did that research for the determination of rough consensus, you may still be aware of one or the other technical argument and I would really appreciate if you could remind me, so that I can address them in my draft--since they likely apply to my draft. -Martin From aerowolf@gmail.com Thu Dec 17 12:43: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 1C46E3A67F8 for ; Thu, 17 Dec 2009 12:43:03 -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 Dev6fa095y2A for ; Thu, 17 Dec 2009 12:43:02 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 6D7FC3A62C1 for ; Thu, 17 Dec 2009 12:43:02 -0800 (PST) Received: by pxi1 with SMTP id 1so1726213pxi.29 for ; Thu, 17 Dec 2009 12:42: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; bh=GIiUFefxgFa+GydmYnbD2tvIMg5tt8/yybwuSEK6VV4=; b=XmQhBZinYIgJTLh++wO+oA8RoKZXeT8x03prPcPVkOFT+u0fLABahboxO5htHCu8NQ zLtu5t29uKfpnBc8PYinW7pj1eCEkODAIaA56ANOesWD6YQP9gDywoesy+zT4z3qgh8q 1nhARMq2jHgg3V7PaTT6yPScX2h3zUqY137O0= 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=Fwpx/YTZ29lmBliNCBhXUoq3eKYs+XKuCMVnUOZlcCGejG9dStPtT08hJdLj0b20jQ i/2NoevZ89NIzEBDaiRlRzEd40nT31Qm0hkyJPxaUcGtwtjz16uneHEVK1SgggNbbCHK v4lDIQTJS7GinLm9jY24pFmIg5L1zv+n1/ZZY= MIME-Version: 1.0 Received: by 10.142.75.21 with SMTP id x21mr1968328wfa.150.1261082565352; Thu, 17 Dec 2009 12:42:45 -0800 (PST) In-Reply-To: <4B29A4A4.1090106@jacaranda.org> References: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> <4B296275.8010108@extendedsubset.com> <4B29A4A4.1090106@jacaranda.org> Date: Thu, 17 Dec 2009 12:42:45 -0800 Message-ID: <6b9359640912171242j73857862n132649c45a25e9d7@mail.gmail.com> From: Kyle Hamilton To: David-Sarah Hopwood Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 20:43:03 -0000 On Wed, Dec 16, 2009 at 7:25 PM, David-Sarah Hopwood wrote: >> In short, everyone* needs to patch and disable compatible/insecure mode >> as soon as is practical. >> >> *Except those who can prove that their endpoint cannot renegotiate and >> will never be willing to talk to a server that can possibly renegotiate. > > No, even those. > > If any server does not patch, it will soon fail to be interoperable with > clients that require patched servers. And if the patches to the server include patches that are not desired by the entity running the server? The only option then is to divert incredible amounts of resources (especially to a tiny operation -- remember, small business accounts for 80% of economic growth in the United States, according to the Small Business Administration) to changing to a different server, with different code and interface requirements. -Kyle H From Pasi.Eronen@nokia.com Thu Dec 17 13: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 253D43A67F3 for ; Thu, 17 Dec 2009 13:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 R2Azk5PNE+td for ; Thu, 17 Dec 2009 13:31:41 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7D9BA3A6778 for ; Thu, 17 Dec 2009 13:31:40 -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 nBHLVKZP027409 for ; Thu, 17 Dec 2009 23:31:23 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 23:28:53 +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, 17 Dec 2009 23:28:49 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 17 Dec 2009 22:28:48 +0100 From: To: Date: Thu, 17 Dec 2009 22:28:47 +0100 Thread-Topic: Summarizing identity change discussion so far Thread-Index: Acp35q+5MB/IK2o8TM+TSRCqs64JxAHeEGWw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F77BBB@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@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: 17 Dec 2009 21:28:49.0030 (UTC) FILETIME=[EBED5260:01CA7F5F] X-Nokia-AV: Clean Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 21:31:42 -0000 Here's proposed text for the Security Considerations section about the identity changes. The discussion on the list seemed to favor keeping the normative parts quite mild, so much of this is worded as advice for people to consider (or ignore, if they so choose), not as strict=20 requirements: While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. In particular, either the client or the server can during renegotiation present a different certificate than was used earlier, and this may become as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way. =20 TLS implementers are encouraged to clearly document how renegotiation interacts with the APIs offered to applications (for example, which API calls might return different values on different calls, or which callbacks might get called multiple times). To make life simpler for applications that do not expect the peer's certificate to change once it's been authentication, TLS implementations MAY offer the applications the option abort the renegotiation if the peer tries to authenticate with a different certificate and/or different server name (in the server_name extension) than was used earlier. However, enabling this option by default for all applications could break existing applications that depend on using renegotiation to present multiple certificates. TLS implementations SHOULD also offer the applications the option to disable renegotiation completely. Finally, designers of applications that depend on renegotiation are reminded that many TLS APIs represent application data as a simple octet stream; applications may not be able to determine exactly which application data octets were received before, during, or after renegotiation. Especially if the peer presents a different=20 certificate during renegotiation, care is needed when specifying how the application should handle the data. Comments (and especially concrete proposals for improving the text) are welcome. Best regards, Pasi > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Eronen Pasi (Nokia-NRC/Helsinki) > Sent: 08 December, 2009 11:13 > To: tls@ietf.org > Subject: [TLS] Summarizing identity change discussion so far >=20 > (wearing Area Director hat) >=20 > Although the IETF Last Call is still underway, here's a short attempt > to summarize the discussion regarding identity changes (Section 7) so > far: >=20 > - We seem to agree that changing the certificate/identity > during secure renegotiation (so there's no man-in-the-middle, just two > parties) could confuse some applications. James Manger's email > provides > IMHO a good example of what that confusion could be (in this particular > example, the confusion has security implications, too): >=20 > http://www.ietf.org/mail-archive/web/tls/current/msg05122.html >=20 > - We mostly seem to agree that some applications could not just handle > certificate/identity changes correctly, but would actually benefit > from them. >=20 > - We seem to agree that it would be a reasonable idea for the TLS > library to offer the applications an option where the TLS library > checks that the certificate doesn't change during renegotiation. > This is an *option* -- an application could decide not to use it, > and e.g. do more complex comparisons. >=20 > - We have much less support for requiring that every TLS library > MUST implement this functionality and/or MUST enable it by default > (whatever "by default" means in your API), at least in this draft. >=20 > Unless I'm badly misreading the situation, or it significantly changes > during the rest of the IETF Last Call, my proposal here would be as > follows: >=20 > - We do NOT require (with "MUST") any changes to TLS libraries in this > regard. >=20 > - We describe the situation a bit more clearly than the current text > does (it seems many people found the current text somewhat unclear). >=20 > - We recommend that TLS libraries SHOULD provide identity matching > (with memcmp, abort handshake if changed) functionality to > applications, and SHOULD allow applications to enable/disable this > functionality. >=20 > - We include a sentence or two describing the pros and cons of > enabling/not enabling this feature by default, but don't require or > recommend any particular default value. >=20 > - The text probably needs to note that if the applications wants to > deal with identity changes, it may need to consider the "which > application_data byte(s) correspond to which identity" question (or it > may not -- the answer may depend a lot on the application protocol). >=20 > Does this sound like a reasonable approach? >=20 > Best regards, > Pasi > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From aerowolf@gmail.com Thu Dec 17 13:36: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 3EA133A68F7 for ; Thu, 17 Dec 2009 13:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_15=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 WVw+SUHK4IRC for ; Thu, 17 Dec 2009 13:36:11 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 8687A3A67E4 for ; Thu, 17 Dec 2009 13:36:11 -0800 (PST) Received: by pxi1 with SMTP id 1so1753863pxi.29 for ; Thu, 17 Dec 2009 13:35:54 -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=WPZW6p+DnH40k39AfWYSWHC2Oy+JSUa1NpjNfbrApiA=; b=i2hDXVnmozIngyeJ5kJI9U+70iDfyCeJBH2lBGvjsn9owWryYwANwZIS+/ZwryGdc3 yekg/dvL+wdQYiE1fpSWfEgR5z7u2kkKGAH1q8uU258e1V99Pnl8stcQZAAjzwcEM5WF +bGAmhzD2yoEgl+XpM6L2Y77OT4oK2mbMGfLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sdGq/+huA9b+2PwO4Cp0Qh9G8zYO1w1CubJ/v43a7jyXMzouDiAyvUKE2ag8mHjvKa +1VIM7vToBYVohPWUfoLM35bJDsxewekRs2E4nINkFtk0NrhjCGhnYCQ96lA3uRaq8cn 319vOL5mpAc9/a2bokpioYpjKZJXeSctfOLZA= MIME-Version: 1.0 Received: by 10.142.55.14 with SMTP id d14mr1994249wfa.45.1261085754647; Thu, 17 Dec 2009 13:35:54 -0800 (PST) Date: Thu, 17 Dec 2009 13:35:54 -0800 Message-ID: <6b9359640912171335s76c04cc7o9434986d236c334b@mail.gmail.com> From: Kyle Hamilton To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [TLS] Query for consensus on an "experimental/private-use" extension identifier X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 21:36:12 -0000 I would like to attempt to initiate the "IETF Consensus" process for assigning a single "experimental/private-use" extension identifier. I can submit an I-D to describe how I feel this could be interoperable and multiplexable, so that the "private-use" mechanism can be used between compliant implementations without fear of trampling over each other. (I've got a design where multiple extensions are necessary to transfer information about authentication requirements and authorization capabilities, while blinding them to the client unless the client has a trust anchor that can un-blind them). Would there be interest in this beyond just me? My current experiment is an attempt to reduce the amount of information leakage produced by the "allowed CA names" field, by sending salted hashes of each of either the CA names or trust anchor AKIDs that the peer is willing to accept as authenticators, shashed (shash = s(alted )hash) such that an attacker would need to have the same trust anchor in its repository to identify exactly which CAs it knows about that can and will be accepted by the peer. I would like to suggest 34 as the new extension ID for this, since according to IANA it's the highest unassigned possible value (35 is used for SessionTicket). What is the procedure to attempt to initiate this kind of IETF consensus, necessary to be able to experiment without fear of smashing someone else's experiments? (As I said, I'll draw up an I-D to more concretely define the semantics of such an extension, including the ability to interleave multiple types of extensions under the same extension identifier.) -Kyle H From aerowolf@gmail.com Thu Dec 17 13: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 74FA33A68AF for ; Thu, 17 Dec 2009 13:37:35 -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 LPZFFDx6TzrQ for ; Thu, 17 Dec 2009 13:37:34 -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 C58213A681A for ; Thu, 17 Dec 2009 13:37:34 -0800 (PST) Received: by pwi20 with SMTP id 20so1665996pwi.29 for ; Thu, 17 Dec 2009 13:37:16 -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=BskSGSx7n1Nv/bSQVmbPMqUTHGoapNxqADFZFJTWkSE=; b=A53bGrAqbGyHs7vYretfYMRYmc2oSuNXcV+xJagcQpLO/OlLyRIt585SlCYhaNdVmj ffYhb/M2qKF6vr7EsiworjWdSJUdJYNY4IoJe9vZ31hpWU0FHZUrW96aiyXTLVgy/awT 84/RG+GF0K5+YJWg3gCimngtchZ77SQa2fAls= 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=DvxLB+aG6TplqRTcCJWztc7lML4KdQ89Lpj/yAxVgMW7ymKeDhSw3iLRtKzgmzAmVX L/24rlmMO8a0QQoaA6E/S5fu75MCd9iw6+EoMYpd2GdLNiEQEyBIYYH1FrLvmi/z94cd iXporu14N0r5TrIzLN3TYYLKkr00tDp3N58b4= MIME-Version: 1.0 Received: by 10.142.2.14 with SMTP id 14mr1997604wfb.15.1261085835885; Thu, 17 Dec 2009 13:37:15 -0800 (PST) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 17 Dec 2009 13:37:15 -0800 Message-ID: <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> From: Kyle Hamilton To: Pasi.Eronen@nokia.com Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 21:37:35 -0000 On Tue, Dec 8, 2009 at 1:13 AM, wrote: > (wearing Area Director hat) > > - We recommend that TLS libraries SHOULD provide identity matching > (with memcmp, abort handshake if changed) functionality to > applications, and SHOULD allow applications to enable/disable this > functionality. No, identity matching SHOULD be done in accordance with PKIX. memcmp is not at all sufficient. However, I would support the following: - TLS libraries SHOULD provide identity matching services between and throughout renegotiation handshakes. Libraries SHOULD implement this in accordance with PKIX [PKIX], but MAY do so with a direct memory comparison. Implementors are cautioned that this latter approach does not provide for changing the cipher parameters -- such as a renegotiation with an EC or DH certificate after identification with an RSA certificate. If the identity matching service fails to match the identity, implementations MUST abort the handshake with a fatal bad_certificate alert. -Kyle H From marsh@extendedsubset.com Thu Dec 17 13: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 B27A43A6832 for ; Thu, 17 Dec 2009 13:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltO5q91azFaV for ; Thu, 17 Dec 2009 13:38: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 2780E3A6403 for ; Thu, 17 Dec 2009 13:38:08 -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 1NLO2j-000Lr7-Bz; Thu, 17 Dec 2009 21:37:53 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4892B6678; Thu, 17 Dec 2009 21:37:51 +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/S9Wpq4n3QHFBie8JXnXlgmhAbGWrnjaY= Message-ID: <4B2AA4AE.5070306@extendedsubset.com> Date: Thu, 17 Dec 2009 15:37:50 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912171858.nBHIwG5H008367@fs4113.wdf.sap.corp> In-Reply-To: <200912171858.nBHIwG5H008367@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-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 21:38:09 -0000 Martin Rex wrote: > Marsh Ray wrote: >>> But as I described, >>> these are going to be servers that do not renegotiate anyway, >> TLS does not define such a thing as a "server that does not >> renegotiate". There may be in fact some application protocols or servers >> which do not, but TLS provide no way to indicate this in the handshake. > > As evident from rfc-5246 Appendix D. renegotiation is an optional > feature of the SSLv3/TLS protocol family and not available in all > implementations of SSLv3/TLS. > > Since you are still listed as an author of the spec, (Shhh...I'm hoping they don't catch on.) > I consider > your interpretation fairly authoritative for what the spec intends > to say. As you wish, I shall interpret this matter to the full extent of my authority. > --which means that there is a defect, because it does currently > _not_ specify the behaviour for non-renegotiating servers A protocol spec that says "this is how an initial handshake is to be done" and "this is how a renegotiating handshake works" is not defective simply because some uses of the protocol choose not to do renegotiation. > (which you incorrectly assumed to not exist). I have done nothing of the sort. I am quite sure there are TLS clients and servers which absolutely do not renegotiate. I don't think any of the widely used general purpose implementations are in that category. But the TLS specs don't define this in the protocol such that it can communicated as part of the handshake which establishes the security parameters. Therefore it is not useful in making security decisions at the TLS level. > Please fix this defect _before_ publishing this specification. I don't see it, sorry. > The only reason why secure TLS renegotiation can be considered > an update to the existing installed base at all (and not a different > non-interoperable protocol), is that renegotiation has never been > a core element of SSLv3/TLS and is optional-to-implement. That doesn't make sense to me. > Essentially, the secure renegotiation spec is deprecating the > old renegotiation and defining a new, optional, secure renegotiation. Don't forget the initial handshake has new requirements, too. > Describing potential vulnerabilities from using backwards-interoble > renegotiation with the installed base and discouraging the use of > that old optional feature is fine. Encouraging the use the > new optional and secure renegotiation is also no problem. > Describing security implications of old TLS peers that still > offer old renegotiation is also no problem. > > Discouraging the interoperability with compliant but > not updated SSLv3->TLSv1.2 on the core protocol elements > (aka initial TLS handshake) is inacceptable, Yes, my personal and professional mission is to discourage interoperability where such interoperability does not deliver the stated and implied guarantees for the security of the data. Too bad if you don't like it. My own livelihood, as well as that of most of my friends, depends pretty directly on the security of this protocol. I have personally recommended enough SSL/TLS-based soultions at this point that I feel quite obligated to work on keeping it healthy. Nevertheless, the wording of the current spec leaves the option of interoperating (possibly insecurely) with unpatched endpoints up to vendors and their customers to decide. My personal recommendation is to be in this compatible mode for as short a time as possible because it does not offer the full security guarantees intended for TLS. And I'm not letting folks go around making misrepresentations about the security of broken versions of it. > because it would > make updated TLS peers non-compliant with the original TLS spec, > which implies these peers are using a different protocol. As well they should, because the current SSLv3 and TLS specs are broken, in a worse way even than SSLv2. - Marsh From mrex@sap.com Thu Dec 17 13:45: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 D69E93A68D9 for ; Thu, 17 Dec 2009 13:45:30 -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 tIHG23WlULm6 for ; Thu, 17 Dec 2009 13:45: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 C93A03A6820 for ; Thu, 17 Dec 2009 13:45:29 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBHLjE3B004904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 22:45:14 +0100 (MET) From: Martin Rex Message-Id: <200912172145.nBHLjDUT018568@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Thu, 17 Dec 2009 22:45:13 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BBB@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 17, 9 10:28: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] Summarizing identity change discussion so far 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, 17 Dec 2009 21:45:31 -0000 Pasi.Eronen@nokia.com wrote: > > Comments (and especially concrete proposals for improving the text) > are welcome. Sounds good to me. (I leave two typos I think to have noticed to the native speakers). Maybe we should at least mention one valid reason for why a certificate may change in the Security Considerations: certificate update/renewal. There were two scenarios mentioned where this seems to be a regular use case IIRC. Was it gaming where they were using quite short-lived certificates and then XMPP, where they were using quite long-lived connections? -Martin From marsh@extendedsubset.com Thu Dec 17 14:01: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 BB5563A6918 for ; Thu, 17 Dec 2009 14:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4-2aUsfg1tw for ; Thu, 17 Dec 2009 14:01:54 -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 E194F3A6910 for ; Thu, 17 Dec 2009 14:01:53 -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 1NLOPj-000KT2-3L; Thu, 17 Dec 2009 22:01:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DA68D6678; Thu, 17 Dec 2009 22:01:37 +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/fNnlFdeWIH7deZvweevek7JusYt/okdE= Message-ID: <4B2AAA40.3090804@extendedsubset.com> Date: Thu, 17 Dec 2009 16:01:36 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BBB@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BBB@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 22:01:54 -0000 Looks great to me. A few edit suggestions inline. - Marsh Pasi.Eronen@nokia.com wrote: > Here's proposed text for the Security Considerations section about the > identity changes. The discussion on the list seemed to favor keeping > the normative parts quite mild, so much of this is worded as advice > for people to consider (or ignore, if they so choose), not as strict > requirements: > > While this extension mitigates the man-in-the-middle attack > described in the overview, it does not resolve all possible > problems an application may face if it is unaware of renegotiation. > In particular, either the client or the server can during For example, during renegotiation either the client or the server can present... > renegotiation present a different certificate than was used > earlier, and this may become as a surprise to application earlier. This may come as a surprise > developers (who might have expected, for example, that a > "getPeerCertificates()" API call returns the same value if called > twice), and might be handled in an insecure way. > > TLS implementers are encouraged to clearly document how > renegotiation interacts with the APIs offered to applications (for > example, which API calls might return different values on different > calls, or which callbacks might get called multiple times). > > To make life simpler for applications that do not expect the peer's > certificate to change once it's been authentication, TLS > implementations MAY offer the applications the option abort the how about: "are encouraged to offer" ? > renegotiation if the peer tries to authenticate with a different > certificate and/or different server name (in the server_name > extension) than was used earlier. However, enabling this option by > default for all applications could break existing applications that > depend on using renegotiation to present multiple certificates. > TLS implementations SHOULD also offer the applications the option > to disable renegotiation completely. Consider moving this sentence above the MAY, perhaps in its own paragraph. > Finally, designers of applications that depend on renegotiation are > reminded that many TLS APIs represent application data as a simple > octet stream; applications may not be able to determine exactly > which application data octets were received before, during, or > after renegotiation. Especially if the peer presents a different > certificate during renegotiation, care is needed when specifying > how the application should handle the data. - Marsh From Pasi.Eronen@nokia.com Thu Dec 17 14: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 1F1143A68D9 for ; Thu, 17 Dec 2009 14:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 YJlYFGQvX+LK for ; Thu, 17 Dec 2009 14:06:41 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EA1193A6778 for ; Thu, 17 Dec 2009 14:06:40 -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 nBHM6C9N021972; Thu, 17 Dec 2009 16:06:24 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 00:06:22 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 00:06:13 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 17 Dec 2009 23:06:12 +0100 From: To: Date: Thu, 17 Dec 2009 23:06:10 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp/YSMJ21qxpPadSkKKYtCdVu/oAQAACc+A Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> In-Reply-To: <6b9359640912171337j7ed5be63gf431e0fb12070944@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: 17 Dec 2009 22:06:13.0751 (UTC) FILETIME=[25E29070:01CA7F65] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 22:06:42 -0000 S3lsZSBIYW1pbHRvbiB3cm90ZToNCg0KPiBObywgaWRlbnRpdHkgbWF0Y2hpbmcgU0hPVUxEIGJl IGRvbmUgaW4gYWNjb3JkYW5jZSB3aXRoIFBLSVguICBtZW1jbXANCj4gaXMgbm90IGF0IGFsbCBz dWZmaWNpZW50Lg0KPiANCj4gSG93ZXZlciwgSSB3b3VsZCBzdXBwb3J0IHRoZSBmb2xsb3dpbmc6 DQo+IA0KPiAtIFRMUyBsaWJyYXJpZXMgU0hPVUxEIHByb3ZpZGUgaWRlbnRpdHkgbWF0Y2hpbmcg c2VydmljZXMgYmV0d2VlbiBhbmQNCj4gdGhyb3VnaG91dCByZW5lZ290aWF0aW9uIGhhbmRzaGFr ZXMuICBMaWJyYXJpZXMgU0hPVUxEIGltcGxlbWVudCB0aGlzDQo+IGluIGFjY29yZGFuY2Ugd2l0 aCBQS0lYIFtQS0lYXSwgYnV0IE1BWSBkbyBzbyB3aXRoIGEgZGlyZWN0IG1lbW9yeQ0KPiBjb21w YXJpc29uLiAgSW1wbGVtZW50b3JzIGFyZSBjYXV0aW9uZWQgdGhhdCB0aGlzIGxhdHRlciBhcHBy b2FjaCBkb2VzDQo+IG5vdCBwcm92aWRlIGZvciBjaGFuZ2luZyB0aGUgY2lwaGVyIHBhcmFtZXRl cnMgLS0gc3VjaCBhcyBhDQo+IHJlbmVnb3RpYXRpb24gd2l0aCBhbiBFQyBvciBESCBjZXJ0aWZp Y2F0ZSBhZnRlciBpZGVudGlmaWNhdGlvbiB3aXRoDQo+IGFuIFJTQSBjZXJ0aWZpY2F0ZS4gIElm IHRoZSBpZGVudGl0eSBtYXRjaGluZyBzZXJ2aWNlIGZhaWxzIHRvIG1hdGNoDQo+IHRoZSBpZGVu dGl0eSwgaW1wbGVtZW50YXRpb25zIE1VU1QgYWJvcnQgdGhlIGhhbmRzaGFrZSB3aXRoIGEgZmF0 YWwNCj4gYmFkX2NlcnRpZmljYXRlIGFsZXJ0Lg0KDQpXZWxsLCB0aGUgdGV4dCBJIHByb3Bvc2Vk IGp1c3Qgc2FpZCAiZGlmZmVyZW50IGNlcnRpZmljYXRlIiwgbm90DQoibWVtY21wIi4gSSBrbm93 IHRoYXQncyBhIGJpdCB2YWd1ZSwgYnV0ICJpbiBhY2NvcmRhbmNlIHdpdGggUEtJWA0KW1BLSVhd IiBpcyBub3QgdmVyeSBwcmVjaXNlIGVpdGhlciwgYW5kIHdvdWxkIG5lZWQgYSBtb3JlIHNwZWNp ZmljDQpyZWZlcmVuY2UgdG8gd2hlcmUgZXhhY3RseSB0aGUgZGV0YWlscyBhcmUgKGZvciBleGFt cGxlLCBpdCBjYW4ndCBtZWFuDQpjb21wYXJpbmcgdGhlIFN1YmplY3QgZmllbGQsIHNpbmNlIFBL SVggYWxsb3dzIGxlYXZpbmcgaXQgZW1wdHkpLg0KDQpBbmQgdGhlIGNlcnRpZmljYXRlIG1pZ2h0 IGhhdmUgZXh0ZW5zaW9ucyAoY2VydGlmaWNhdGUgcG9saWNpZXMsDQpzdWJqZWN0IGRpcmVjdG9y eSBhdHRyaWJ1dGVzLCBleHRlbmRlZCBrZXkgdXNhZ2UsIGV0Yy4pIHdoZXJlIGNoYW5nZXMNCmJl dHdlZW4gQVBJIGNhbGxzIGNvdWxkIHN1cnByaXNlIHRoZSBhcHBsaWNhdGlvbi4NCg0KSGVyZSdz IGFub3RoZXIgc2hvdCBhdCB0aGF0IHBhcmFncmFwaCAoYWxzbyBpbmNsdWRpbmcgc3VnZ2VzdGlv bnMNCmZyb20gTWFyc2gncyBlbWFpbCk6DQoNCiAgIFRMUyBpbXBsZW1lbnRhdGlvbnMgU0hPVUxE IG9mZmVyIHRoZSBhcHBsaWNhdGlvbnMgdGhlIG9wdGlvbiB0bw0KICAgZGlzYWJsZSByZW5lZ290 aWF0aW9uIGNvbXBsZXRlbHkuDQoNCiAgIFRvIG1ha2UgbGlmZSBzaW1wbGVyIGZvciBhcHBsaWNh dGlvbnMgdGhhdCBkbyBub3QgZXhwZWN0IHRoZSBwZWVyJ3MNCiAgIGNlcnRpZmljYXRlIHRvIGNo YW5nZSBvbmNlIGl0J3MgYmVlbiBhdXRoZW50aWNhdGVkLCBUTFMNCiAgIGltcGxlbWVudGF0aW9u cyBtYXkgYWxzbyB3aXNoIHRvIG9mZmVyIHRoZSBhcHBsaWNhdGlvbnMgdGhlIG9wdGlvbg0KICAg YWJvcnQgdGhlIHJlbmVnb3RpYXRpb24gaWYgdGhlIHBlZXIgdHJpZXMgdG8gYXV0aGVudGljYXRl IHdpdGggYQ0KICAgZGlmZmVyZW50IGNlcnRpZmljYXRlIGFuZC9vciBkaWZmZXJlbnQgc2VydmVy IG5hbWUgKGluIHRoZQ0KICAgc2VydmVyX25hbWUgZXh0ZW5zaW9uKSB0aGFuIHdhcyB1c2VkIGVh cmxpZXIuIEhvd2V2ZXIsIGVuYWJsaW5nDQogICB0aGlzIG9wdGlvbiBieSBkZWZhdWx0IGZvciBh bGwgYXBwbGljYXRpb25zIGNvdWxkIGJyZWFrIGV4aXN0aW5nDQogICBhcHBsaWNhdGlvbnMgdGhh dCBkZXBlbmQgb24gdXNpbmcgcmVuZWdvdGlhdGlvbiB0byBjaGFuZ2UgZnJvbSBvbmUNCiAgIGNl cnRpZmljYXRlIHRvIGFub3RoZXIuIChGb3IgZXhhbXBsZSwgbG9uZy1saXZlZCBUTFMgY29ubmVj dGlvbnMNCiAgIGNvdWxkIGNoYW5nZSB0byBhIHJlbmV3ZWQgY2VydGlmaWNhdGU7IG9yIHJlbmVn b3RpYXRpb24gY291bGQNCiAgIHNlbGVjdCBhIGRpZmZlcmVudCBjaXBoZXIgc3VpdGUgdGhhdCBy ZXF1aXJlcyB1c2luZyBhIGRpZmZlcmVudA0KICAgY2VydGlmaWNhdGUuKQ0KDQpCZXN0IHJlZ2Fy ZHMsDQpQYXNpDQo= From mickgray@au1.ibm.com Thu Dec 17 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 DC4AF3A68EC for ; Thu, 17 Dec 2009 14:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 iypv6WXJY5dw for ; Thu, 17 Dec 2009 14:16:59 -0800 (PST) Received: from e23smtp08.au.ibm.com (e23smtp08.au.ibm.com [202.81.31.141]) by core3.amsl.com (Postfix) with ESMTP id C9FE83A6778 for ; Thu, 17 Dec 2009 14:16:57 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp08.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBI9Gfgi016816 for ; Fri, 18 Dec 2009 20:16:41 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBHMCgtM1519744 for ; Fri, 18 Dec 2009 09:12:42 +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 nBHMGfQT019568 for ; Fri, 18 Dec 2009 09:16:41 +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 nBHMGf4f019560; Fri, 18 Dec 2009 09:16:41 +1100 In-Reply-To: <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> To: Kyle Hamilton X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Fri, 18 Dec 2009 08:16:29 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 18/12/2009 09:23:46 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 22:17:00 -0000 Kyle Hamilton wrote: > On Tue, Dec 8, 2009 at 1:13 AM, wrote: > > (wearing Area Director hat) > > > > - We recommend that TLS libraries SHOULD provide identity matching > > (with memcmp, abort handshake if changed) functionality to > > applications, and SHOULD allow applications to enable/disable this > > functionality. > > No, identity matching SHOULD be done in accordance with PKIX. memcmp > is not at all sufficient. > > However, I would support the following: > > - TLS libraries SHOULD provide identity matching services between and > throughout renegotiation handshakes. Libraries SHOULD implement this > in accordance with PKIX [PKIX], but MAY do so with a direct memory > comparison. Implementors are cautioned that this latter approach does > not provide for changing the cipher parameters -- such as a > renegotiation with an EC or DH certificate after identification with > an RSA certificate. If the identity matching service fails to match > the identity, implementations MUST abort the handshake with a fatal > bad_certificate alert. I am also in favour of this wording or wording to that effect. - Mick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Thu Dec 17 14: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 8F9103A6914 for ; Thu, 17 Dec 2009 14:18:40 -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 crfqso9t8hnC for ; Thu, 17 Dec 2009 14:18: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 7748B3A6778 for ; Thu, 17 Dec 2009 14:18:38 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBHMIMtr029403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 23:18:22 +0100 (MET) From: Martin Rex Message-Id: <200912172218.nBHMILwN020589@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Thu, 17 Dec 2009 23:18:21 +0100 (MET) In-Reply-To: <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> from "Kyle Hamilton" at Dec 17, 9 01:37: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] Summarizing identity change discussion so far 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, 17 Dec 2009 22:18:40 -0000 Kyle Hamilton wrote: > > On Tue, Dec 8, 2009 at 1:13 AM, wrote: > > (wearing Area Director hat) > > > > - We recommend that TLS libraries SHOULD provide identity matching > > (with memcmp, abort handshake if changed) functionality to > > applications, and SHOULD allow applications to enable/disable this > > functionality. > > No, identity matching SHOULD be done in accordance with PKIX. memcmp > is not at all sufficient. > > However, I would support the following: > > - TLS libraries SHOULD provide identity matching services between and > throughout renegotiation handshakes. Libraries SHOULD implement this > in accordance with PKIX [PKIX], but MAY do so with a direct memory > comparison. Implementors are cautioned that this latter approach does > not provide for changing the cipher parameters -- such as a > renegotiation with an EC or DH certificate after identification with > an RSA certificate. If the identity matching service fails to match > the identity, implementations MUST abort the handshake with a fatal > bad_certificate alert. The way the TLS specifications are currently archtected, this is a service that is _not_ available from TLS. Although there is likely some PKI(X)-Software available to the TLS implementation for the X.509 stuff and certificate path validation processing, but it can easily be that it is a completely different module. If an application currently wants to look at the contents of the certificates exchanged and authenticated during the TLS handshake, then this is explicitly declared out-of-scope for TLS in the base spec (RFC-5246, section 1. last paragraph). I would strongly recommend to leave the code slicing (modularization) between application, PKI-Software and TLS-implementation outside the scope of this spec. -Martin From Pasi.Eronen@nokia.com Thu Dec 17 14: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 0C20E3A68EC for ; Thu, 17 Dec 2009 14:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_15=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 ntCxHKs3dJCI for ; Thu, 17 Dec 2009 14:28:08 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E324B3A6926 for ; Thu, 17 Dec 2009 14:28:07 -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 nBHMRPkt006948; Thu, 17 Dec 2009 16:27:51 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 00:26:04 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 00:25:59 +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); Fri, 18 Dec 2009 00:25:54 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 17 Dec 2009 23:25:53 +0100 From: To: , Date: Thu, 17 Dec 2009 23:25:51 +0100 Thread-Topic: [TLS] Query for consensus on an "experimental/private-use" extension identifier Thread-Index: Acp/YPharOwd2v31RfW9Zv2ytC4v7wABF3yw Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31F77BEE@NOK-EUMSG-01.mgdnok.nokia.com> References: <6b9359640912171335s76c04cc7o9434986d236c334b@mail.gmail.com> In-Reply-To: <6b9359640912171335s76c04cc7o9434986d236c334b@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2009 22:25:54.0593 (UTC) FILETIME=[E5B8C110:01CA7F67] X-Nokia-AV: Clean Subject: Re: [TLS] Query for consensus on an "experimental/private-use" extension identifier X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 22:28:09 -0000 The "IETF Consensus" number allocation process is described in RFC 2434: it means writing an Internet-Draft, and getting it published=20 as an IETF stream RFC (the actual allocation happens when the=20 draft has been approved by the IESG). However, I'd like to add that often such "private use" identifiers are intentionally designed so that they would trample over each other (so that they only work for private use/mutually agreed experiments, and are not used just to avoid going through the IETF process).=20 If we, for example, created a "private use" extension where the first 4 bytes are the Enterprise Number (which anyone can get just by filling a web form), the effect would probably be pretty much the same as changing the IANA allocation policy for the whole registry to "First Come First Served". Best regards, Pasi > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Kyle Hamilton > Sent: 17 December, 2009 23:36 > To: tls@ietf.org > Subject: [TLS] Query for consensus on an "experimental/private-use" > extension identifier >=20 > I would like to attempt to initiate the "IETF Consensus" process for > assigning a single "experimental/private-use" extension identifier. I > can submit an I-D to describe how I feel this could be interoperable > and multiplexable, so that the "private-use" mechanism can be used > between compliant implementations without fear of trampling over each > other. >=20 > (I've got a design where multiple extensions are necessary to transfer > information about authentication requirements and authorization > capabilities, while blinding them to the client unless the client has > a trust anchor that can un-blind them). >=20 > Would there be interest in this beyond just me? My current experiment > is an attempt to reduce the amount of information leakage produced by > the "allowed CA names" field, by sending salted hashes of each of > either the CA names or trust anchor AKIDs that the peer is willing to > accept as authenticators, shashed (shash =3D s(alted )hash) such that an > attacker would need to have the same trust anchor in its repository to > identify exactly which CAs it knows about that can and will be > accepted by the peer. >=20 > I would like to suggest 34 as the new extension ID for this, since > according to IANA it's the highest unassigned possible value (35 is > used for SessionTicket). >=20 > What is the procedure to attempt to initiate this kind of IETF > consensus, necessary to be able to experiment without fear of smashing > someone else's experiments? >=20 > (As I said, I'll draw up an I-D to more concretely define the > semantics of such an extension, including the ability to interleave > multiple types of extensions under the same extension identifier.) >=20 > -Kyle H > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mickgray@au1.ibm.com Thu Dec 17 14: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 C58703A69C1 for ; Thu, 17 Dec 2009 14:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 43MpJ8akZMBR for ; Thu, 17 Dec 2009 14:40:03 -0800 (PST) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by core3.amsl.com (Postfix) with ESMTP id A44333A68C1 for ; Thu, 17 Dec 2009 14:40:02 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp02.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBHMb1Ku024796 for ; Fri, 18 Dec 2009 09:37:01 +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 nBHMZkL21503388 for ; Fri, 18 Dec 2009 09:35:47 +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 nBHMdjdG004725 for ; Fri, 18 Dec 2009 09:39:46 +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 nBHMdjmp004722 for ; Fri, 18 Dec 2009 09:39:45 +1100 In-Reply-To: <200912172218.nBHMILwN020589@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Fri, 18 Dec 2009 08:39:25 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 18/12/2009 09:46:50 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org, Kyle Hamilton Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 22:40:03 -0000 mrex@sap.com wrote: > Kyle Hamilton wrote: > > > > On Tue, Dec 8, 2009 at 1:13 AM, wrote: > > > (wearing Area Director hat) > > > > > > - We recommend that TLS libraries SHOULD provide identity matching > > > (with memcmp, abort handshake if changed) functionality to > > > applications, and SHOULD allow applications to enable/disable this > > > functionality. > > > > No, identity matching SHOULD be done in accordance with PKIX. memcmp > > is not at all sufficient. > > > > However, I would support the following: > > > > - TLS libraries SHOULD provide identity matching services between and > > throughout renegotiation handshakes. Libraries SHOULD implement this > > in accordance with PKIX [PKIX], but MAY do so with a direct memory > > comparison. Implementors are cautioned that this latter approach does > > not provide for changing the cipher parameters -- such as a > > renegotiation with an EC or DH certificate after identification with > > an RSA certificate. If the identity matching service fails to match > > the identity, implementations MUST abort the handshake with a fatal > > bad_certificate alert. > > The way the TLS specifications are currently archtected, this is > a service that is _not_ available from TLS. > > Although there is likely some PKI(X)-Software available to the > TLS implementation for the X.509 stuff and certificate path validation > processing, but it can easily be that it is a completely different > module. > > If an application currently wants to look at the contents of > the certificates exchanged and authenticated during the TLS handshake, > then this is explicitly declared out-of-scope for TLS in the base spec > (RFC-5246, section 1. last paragraph). I would strongly recommend > to leave the code slicing (modularization) between application, > PKI-Software and TLS-implementation outside the scope of this spec. Yes the problem is defining what an identity change is precisely. We know that CA's load all sorts of stuff in to certificates as part of the DN etc and the same identify could have multiple certificates, and could be identified by multiple CAs. If we say that in TLS we are going to check identity then it has to be very precisely defined, or extremely vaguely defined so that the implementation can not be accused of non compliance or invalid/suspect identity matching. Perhaps it needs to be a vague as possible so that TLS implementation can simply push it back to the application layer in practice - Mick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Thu Dec 17 14:53: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 985943A69D4 for ; Thu, 17 Dec 2009 14:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc4e8E-Gzy-h for ; Thu, 17 Dec 2009 14:53:33 -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 D0DDC3A67E5 for ; Thu, 17 Dec 2009 14:53:33 -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 1NLPDi-000K2E-GJ; Thu, 17 Dec 2009 22:53:18 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 352C26678; Thu, 17 Dec 2009 22:53: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: U2FsdGVkX193z5kitAlA42mnclOul+6U7zk3jP7Y1Gs= Message-ID: <4B2AB65B.6080704@extendedsubset.com> Date: Thu, 17 Dec 2009 16:53:15 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Gray 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, Kyle Hamilton Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 22:53:34 -0000 Michael Gray wrote: > > Yes the problem is defining what an identity change is precisely. We know > that CA's load all sorts of stuff in to certificates as part of the DN etc > and the same identify could have multiple certificates, and could be > identified by multiple CAs. If we say that in TLS we are going to check > identity then it has to be very precisely defined, or extremely vaguely > defined so that the implementation can not be accused of non compliance or > invalid/suspect identity matching. Perhaps it needs to be a vague as > possible so that TLS implementation can simply push it back to the > application layer in practice It does seem that in many cases a memcmp() of the certificates is entirely appropriate. It's certainly a well-defined comparison and it avoids getting the TLS spec overly wrapped up in the details of PKIX. As long as people don't start claiming memcmp() is some "official TLS definition of identity". - Marsh From aerowolf@gmail.com Thu Dec 17 14:55: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 43C473A69EE for ; Thu, 17 Dec 2009 14:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQecsG7-plvg for ; Thu, 17 Dec 2009 14:55:40 -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 07F753A69F5 for ; Thu, 17 Dec 2009 14:55:40 -0800 (PST) Received: by pwi20 with SMTP id 20so1705949pwi.29 for ; Thu, 17 Dec 2009 14:55:22 -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=E62g4VKLjiKpfviSyFk0htP2KYeQ1/krpNqWxVY3kZ8=; b=ml//ZHQU8mbzrvwg2YGBKU8YeHPo8WvXRWbz5LrE4KKkzXdmuCcrq1b6fC3ZAucz8W Mz1LK3oTT3Ip6Kj2fJz3HiRpdNw/HjdCMu7gkyOLZAhVZkWY6rdwRkOh/+Wcn2qyGHpp 7x6r2pN9HLonGCVwaWs0pY4jANrcEP5PmipEU= 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=Xddz3/XCvAHUNZ2m7aYMwzJGDud+RSPasaVLhQL1b4UBtuHCpAhHH/j/J+wFp2drwQ ofnotvVeoDZdSrH3Xf7GCbRLx98YwfCvmQhnn79bS0M8Dw0bb8NxTiZmsjeGmew2n2vd SyCfCfG9woE4I9KC6l5Y3u5BHKZRqrx8dZXzE= MIME-Version: 1.0 Received: by 10.142.8.35 with SMTP id 35mr2105517wfh.30.1261090522758; Thu, 17 Dec 2009 14:55:22 -0800 (PST) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com> References: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 17 Dec 2009 14:55:22 -0800 Message-ID: <6b9359640912171455j4c949defu25b5ad79348197da@mail.gmail.com> From: Kyle Hamilton To: Pasi.Eronen@nokia.com Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 22:55:41 -0000 I support making the MCSV mandatory in the ClientHello. The benefit is obvious: the server *knows*, without a doubt, that the client knows how to do secure renegotiation, even if the client doesn't send the extension. This means that servers can relax their "absolutely no renegotiation" stance, in regards to that particular client, in the same way that they could if they received the extension. As far as I can tell, there is no mechanism (other than extensions) for the server to signal the client that it knows how to do the secure renegotiation. As has been discussed, this would be a static set of 6 bytes appended to the ServerHello. I rather disagree with making the RI extension anything other than empty, because each peer *must* (in order to implement it securely) remember the last hashes for that session and compare them to see if they match, else the MITM could just add bogus information that isn't checked and the handshake proceeds anyway -- which violates the authenticity guarantee. If we're going to force the implementors to save the hashes anyway, why should we take the risk of putting them out on the wire? (To avoid a "chosen plaintext" attack... against a key and negotiation that's about to change?) If the values calculated don't match up with what's received from the other end, the ChangeCipherSpec will work but the Finished message won't be able to be decoded, which will cause the connection to be aborted. (However, I do recognize that putting the prior hashes into an RI extension will cause them to be part of the final hash for Finished anyway, without requiring any changes in how the cryptographic system is set up. I'm unhappy with this idea, though, because there are still MANY extension-agnostic clients and servers out there. Clients won't send extensions if they don't have to, and servers won't show that they know about extensions unless the client shows exactly the extension they expect.) If those hashes are saved by each peer (as would be required under this proposal), then it follows that since they're placed under separate cover by the Finished message, they're an appropriate input for the Renegotiation-Finished hash calculation. Again, there's no reason to put them on the wire. What we're looking for isn't really a "session-based" design -- we're simply looking for a way to authenticate future handshakes as following naturally from prior handshakes. The session parameters are frozen by the time ChangeCipherSpec hits; the Finished message is and always has been the time to determine whether the peer understands the cipher spec parameters. Also, it is illegal for any TLS implementation to negotiate NULL-NULL-NULL, and it is illegal for any TLS implementation to transmit application data after the initial handshake has been initiated and before the Finished messages have been generated by both sides. This would suggest that another mitigation for this attack would be to include a zero-length application-data packet in all renegotiations; if one side thinks it's an initial negotiation, and it receives an application data packet under the state that it thinks is NULL-NULL-NULL, it is required that it close the connection with a fatal handshake_failure alert. (The only problem with this potential mitigation is that if the client is connected to the MITM, and the MITM is connected to the server, the MITM could simply strip out the zero-length application-data chunk, since TLS relies on underlying mechanisms to verify that it has a two-way error-detected/corrected clear channel -- TCP/IP, SPX/IPX, a clean serial line, or an MNP5 modem. TLS doesn't try to detect lost chunks from the server.) So, in addition to mandating the MCSV, I also support an empty RI extension as a means of notifying the server that the client knows how to do it. For interoperability and ease of implementation, it's an easy MUST to send both, if the client understands how to send extensions. I'm less happy about forcing the client to understand extensions enough to verify the data being put into the RI extension on subsequent handshakes, but even in that case the ServerHello wouldn't have the correct 6 bytes at the end (for the initial handshake that the client sees) and thus would cause the client to abort with a handshake_failure. (Since the cryptographic properties of the protocol aren't being discussed, it's only a matter of identifying what oversight in the TLS protocol allowed this attack to work, which is simply that a means was found to trick both sides of a connection into believing that the connection was continuous without cryptographic verification.) At least one good thing that the original protocol designers did was to ensure that both peers must renegotiate their own cipher parameters in the event that either side initiates a renegotiation. Since it's mandatory that servers include the bytes after the end of the ClientHello as part of the hash of handshake messages, regardless of whether it can identify them or not (this was the language previous to TLS-EXT), the client can send anything it wants. The server side is a bit more complex: it can't signal anything to the client unless it uses an extension. For the client, it's very easy to compare 6 bytes in memory to verify that the extension exists and is the proper one. It's only if the Finished message happens and it doesn't have the correctly-seeded hash that it's detected as being bogus. (Notably, the TLS specification requires that after the initial negotiation, applications need to be able to interleave data into the connection -- except in the case of ChangeCipherSpec and Finished, where Finished must always be sent immediately after the ChangeCipherSpec is sent. A way to break compatibility with older clients would be to send a zero-length, HMAC'd application data chunk between the ChangeCipherSpec and Finished messages, using the cipher suite that was put into the current connection state by the ChangeCipherSpec, not count it as a handshake message, and only after that send the Finished message precisely as it is calculated elsewhere. I would prefer that it not be broken, but it could be a means by which TLS 1.3+ ensures that the handshakes under its own cover are acceptable.) Once a handshake determined to be bogus, the spec is clear: abort the connection with a handshake_failure alert. I support making what I see is the minimum number of changes in the specification necessary to ensure security, in such a way as to minimize the amount of work to implementation developers. If there is a way that is simpler, I would like to see it. (I'm wondering if it's time to start making breaking changes, and call the result TLS v2.0.) -Kyle H On Thu, Dec 17, 2009 at 3:30 AM, wrote: > Martin Rex worte: > >> I do not fully agree with the AD's determination of rough consensus. >> >> For the MCSV signaling, the real rough consensus is different from >> what Pasi wrote: >> >> http://www.ietf.org/mail-archive/web/tls/current/msg05306.html >> >> A mandatory Client->Server signaling through cipher suite may >> have less fanatic followers by the count of numbers, but technical >> advantages and _no_ technical objections have been raised against it. > > Several people have very clearly and strongly objected to making the > MSCV mandatory-to-include in ClientHello. You seem to be suggesting > that their opinions don't somehow matter because they are, in *your* > opinion, not "technical". > >> The current either cipher suite or empty TLS extension RI signaling >> may have more "pro", but has significant objections against it >> because of the ambiguity, increased complexity, a 4x code size >> burden for old non-rengotiating servers and additional testing >> complexity. > > If the specification text is ambiguous, we obviously need to fix that. > > About the code/testing complexity/effort: I would say most people > believe that no matter what details get selected, this is not a > significant amount of work (so small differences in lines of code or > test cases should not signify much in making the decision). > >> So as far as rough consensus is concerned, it is definitely with the >> approach I described. > > I disagree. > > Best regards, > Pasi > (wearing Security Area Director hat) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mrex@sap.com Thu Dec 17 15:08: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 299193A69EA for ; Thu, 17 Dec 2009 15:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_BIZOP=0.7] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-8QNPgvutfw for ; Thu, 17 Dec 2009 15:08: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 16F203A6976 for ; Thu, 17 Dec 2009 15:08:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBHN80q5021163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 00:08:00 +0100 (MET) From: Martin Rex Message-Id: <200912172307.nBHN7xPC023485@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 18 Dec 2009 00:07:58 +0100 (MET) In-Reply-To: <4B2AA4AE.5070306@extendedsubset.com> from "Marsh Ray" at Dec 17, 9 03:37:50 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-ietf-tls-renegotation: next 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, 17 Dec 2009 23:08:19 -0000 Marsh Ray wrote: > > > The only reason why secure TLS renegotiation can be considered > > an update to the existing installed base at all (and not a different > > non-interoperable protocol), is that renegotiation has never been > > a core element of SSLv3/TLS and is optional-to-implement. There seems to be an illusion that this secure TLS renegotiation update can be forced upon vendors or implementors. No, it can not. There is an incentive called "competitive advantage", but it does not apply to commodity items in the consumer market that are 2+ years old. If you can force anything from those vendors, then it is a switch to disable old renegotiation, in case that is (unintentially) available. That's it. If you really want to do the community a favor, then this update should be so "small&easy" for those vendors that they can actually put it into installed base, even when that is 2+ years old. If the IETF's "solution" is that you can only implement the whole schmear or nothing, then this is not going to happen to the installed base -- and it is not the fault of those vendors, they can point to the IETF, because of a new spec that may cause their customers interop problems in the future. Some vendors will appreciate this as a "business opportunity", but I think this is a big waste of money. -Martin From mrex@sap.com Thu Dec 17 15:12: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 02FB53A682F for ; Thu, 17 Dec 2009 15:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 IzhzHxCjJJFl for ; Thu, 17 Dec 2009 15:12: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 46B863A6976 for ; Thu, 17 Dec 2009 15:12:06 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBHNBhJx023465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 00:11:43 +0100 (MET) From: Martin Rex Message-Id: <200912172311.nBHNBgTi023999@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 18 Dec 2009 00:11:42 +0100 (MET) In-Reply-To: <4B2AB65B.6080704@extendedsubset.com> from "Marsh Ray" at Dec 17, 9 04: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, aerowolf@gmail.com Subject: Re: [TLS] Summarizing identity change discussion so far 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, 17 Dec 2009 23:12:11 -0000 Marsh Ray wrote: > > Michael Gray wrote: > > > > Yes the problem is defining what an identity change is precisely. We know > > that CA's load all sorts of stuff in to certificates as part of the DN etc > > and the same identify could have multiple certificates, and could be > > identified by multiple CAs. If we say that in TLS we are going to check > > identity then it has to be very precisely defined, or extremely vaguely > > defined so that the implementation can not be accused of non compliance or > > invalid/suspect identity matching. Perhaps it needs to be a vague as > > possible so that TLS implementation can simply push it back to the > > application layer in practice > > It does seem that in many cases a memcmp() of the certificates is > entirely appropriate. It's certainly a well-defined comparison and it > avoids getting the TLS spec overly wrapped up in the details of PKIX. > > As long as people don't start claiming memcmp() is some "official TLS > definition of identity". memcmp() is the TLS method to check that the TLS connection parameter "peer certificate" is still the same after renegotiation. Simililarly, memcmp() is the TLS extension RI method to check that the client and the servers notion of the enclosing TLS session is the same during renegotiation. -Martin From mickgray@au1.ibm.com Thu Dec 17 15:13: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 DC9E63A69D4 for ; Thu, 17 Dec 2009 15:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 gf3xfGT7v3RW for ; Thu, 17 Dec 2009 15:13:35 -0800 (PST) Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by core3.amsl.com (Postfix) with ESMTP id D5DC83A682F for ; Thu, 17 Dec 2009 15:13:33 -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 nBHNAABj027071 for ; Fri, 18 Dec 2009 10:10:10 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBHNDHHo1855684 for ; Fri, 18 Dec 2009 10:13:17 +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 nBHNDHXd001405 for ; Fri, 18 Dec 2009 10:13:17 +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 nBHNDH8n001398; Fri, 18 Dec 2009 10:13:17 +1100 In-Reply-To: <4B2AB65B.6080704@extendedsubset.com> To: Marsh Ray X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Fri, 18 Dec 2009 09:13:04 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 18/12/2009 10:20:22 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: tls@ietf.org, Kyle Hamilton Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 23:13:52 -0000 DQpNYXJzaCBSYXkgPG1hcnNoQGV4dGVuZGVkc3Vic2V0LmNvbT4gd3JvdGU6DQo+IE1pY2hhZWwg R3JheSB3cm90ZToNCj4gPg0KPiA+IFllcyB0aGUgcHJvYmxlbSBpcyBkZWZpbmluZyB3aGF0IGFu IGlkZW50aXR5IGNoYW5nZSBpcyBwcmVjaXNlbHkuICBXZQ0Ka25vdw0KPiA+IHRoYXQgQ0EncyBs b2FkIGFsbCBzb3J0cyBvZiBzdHVmZiBpbiB0byBjZXJ0aWZpY2F0ZXMgYXMgcGFydCBvZiB0aGUg RE4NCmV0Yw0KPiA+IGFuZCB0aGUgc2FtZSBpZGVudGlmeSBjb3VsZCBoYXZlIG11bHRpcGxlIGNl cnRpZmljYXRlcywgYW5kIGNvdWxkIGJlDQo+ID4gaWRlbnRpZmllZCBieSBtdWx0aXBsZSBDQXMu ICBJZiB3ZSBzYXkgdGhhdCBpbiBUTFMgd2UgYXJlIGdvaW5nIHRvDQpjaGVjaw0KPiA+IGlkZW50 aXR5IHRoZW4gaXQgaGFzIHRvIGJlIHZlcnkgcHJlY2lzZWx5IGRlZmluZWQsIG9yIGV4dHJlbWVs eSB2YWd1ZWx5DQo+ID4gZGVmaW5lZCBzbyB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBjYW4gbm90 IGJlIGFjY3VzZWQgb2Ygbm9uIGNvbXBsaWFuY2UNCm9yDQo+ID4gaW52YWxpZC9zdXNwZWN0IGlk ZW50aXR5IG1hdGNoaW5nLiAgUGVyaGFwcyBpdCBuZWVkcyB0byBiZSBhIHZhZ3VlIGFzDQo+ID4g cG9zc2libGUgc28gdGhhdCBUTFMgaW1wbGVtZW50YXRpb24gY2FuIHNpbXBseSBwdXNoIGl0IGJh Y2sgdG8gdGhlDQo+ID4gYXBwbGljYXRpb24gbGF5ZXIgaW4gcHJhY3RpY2UNCj4NCj4gSXQgZG9l cyBzZWVtIHRoYXQgaW4gbWFueSBjYXNlcyBhIG1lbWNtcCgpIG9mIHRoZSBjZXJ0aWZpY2F0ZXMg aXMNCj4gZW50aXJlbHkgYXBwcm9wcmlhdGUuIEl0J3MgY2VydGFpbmx5IGEgd2VsbC1kZWZpbmVk IGNvbXBhcmlzb24gYW5kIGl0DQo+IGF2b2lkcyBnZXR0aW5nIHRoZSBUTFMgc3BlYyBvdmVybHkg d3JhcHBlZCB1cCBpbiB0aGUgZGV0YWlscyBvZiBQS0lYLg0KPg0KPiBBcyBsb25nIGFzIHBlb3Bs ZSBkb24ndCBzdGFydCBjbGFpbWluZyBtZW1jbXAoKSBpcyBzb21lICJvZmZpY2lhbCBUTFMNCj4g ZGVmaW5pdGlvbiBvZiBpZGVudGl0eSIuDQoNClllcyBJIHRoaW5rIEkgd2lsbCBmbGlwLWZsb3Ag b24gdGhpcyBhcyBvbiBzZWNvbmQgdGhvdWdodCBJIGRvIG5vdCBzZWUgaG93DQppZGVudGlmeSBt YXRjaGluZyBjYW4gYmUgLXNpbXBseS0gcHJlY2lzZWx5IGRlZmluZWQgaW4gdGhpcyBjYXNlIHdp dGggUEtJWA0KYW5kIHdoYXQgbWFueSB3aWxsIGZlZWwgaXMgYSBub3Rpb24gb2YgaWRlbnRpdHku ICBJZiB3ZSBzdGljayB0byBzaW1wbHkNCm1hdGNoaW5nIHRoZSBUTFMgU2Vzc2lvbiBQYXJhbWV0 ZXIgb2Yg4oCccGVlciBjZXJ0aWZpY2F0ZeKAnSBhcyBQYXNpIGhhcw0Kc3VnZ2VzdGVkIHRoZW4g dGhhdCBtaWdodCBiZSB0aGUgYmVzdCB3ZSBjYW4gZG8uDQoNCkFueXRoaW5nIHRoYXQgaW52b2x2 ZXMgW1BLSVhdIHdvdWxkIGJlIGFuIGFwcHJvcHJpYXRlIHBsYWNlIHRvIHVzZSB0aGUgdGVybQ0K LW1hZ2ljLSAgOi0pDQoNCi0gTWljaw== From aerowolf@gmail.com Thu Dec 17 15:16: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 F3AD528C180 for ; Thu, 17 Dec 2009 15:16:56 -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 PbH6jRp9HNod for ; Thu, 17 Dec 2009 15:16: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 C29233A6A10 for ; Thu, 17 Dec 2009 15:16:41 -0800 (PST) Received: by pzk6 with SMTP id 6so1813018pzk.29 for ; Thu, 17 Dec 2009 15:15:59 -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=yz7LLTfs11pq1kHBBA0tgGoZY+2C2s027Nr4dCycZUw=; b=HDSvf8ifYbVduRB/oD2s/4L2JjlVXKWO4Xo+vGNO/EbKS450XB3uiDIAvpeFoI3Ej5 onMfjOmSbA96vPBSAgSCt3blukQmm6Ztl6X0v+cie7HQqCrTDfBo8FCeieWRgX3a0KQU Xt3tzLuhqmL/QhHYJNI2zX4znhIr9FdEvymPA= 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=JiF7dLmgZO1k5yknBArXCcwJmaN4AyzrS0fmpyYybscODCJZIeLnW9SGlRWtKtQ1ss 0TdOiKBkx+BW2uj0OAuzzLTVNaXgCQnohgJ4GEPrbWYNsL2fvuSbs+DCeMFtMB6FrOJJ mzCRU8pFxIJcNG9kA4fP6xqk0p1Kic8x+edZg= MIME-Version: 1.0 Received: by 10.143.153.38 with SMTP id f38mr2092851wfo.27.1261091759347; Thu, 17 Dec 2009 15:15:59 -0800 (PST) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 17 Dec 2009 15:15:59 -0800 Message-ID: <6b9359640912171515t1ef6f336id71c2ee3baec5c83@mail.gmail.com> From: Kyle Hamilton To: Pasi.Eronen@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 23:16:57 -0000 On Thu, Dec 17, 2009 at 2:06 PM, wrote: > Well, the text I proposed just said "different certificate", not > "memcmp". I know that's a bit vague, but "in accordance with PKIX > [PKIX]" is not very precise either, and would need a more specific > reference to where exactly the details are (for example, it can't mean > comparing the Subject field, since PKIX allows leaving it empty). PKIX allows (and, actually, encourages) Subject to be empty, but only in the case where subjectAlternativeName isn't. There are also cases where subjectAlternativeName can contain the old Subject, and a new Subject nym is included in the certificate. > And the certificate might have extensions (certificate policies, > subject directory attributes, extended key usage, etc.) where changes > between API calls could surprise the application. Then, for those applications, they should be rewritten to terminate the active session when the policies associated with the certificate change (more specifically, when a particular eKU that the application requires in the certificate associated with the connection is no longer asserted by the peer, when the certificate policies change, or whenever some condition set by the application developer is no longer met). Or, the underlying libraries should enforce this (if asked). Either way, terminating the connection and invalidating the session is the easiest way to enforce that all certificate changes come through the "initial request authenticator/authorizer" code path, which is where all of those policies are verified. > Here's another shot at that paragraph (also including suggestions > from Marsh's email): > > =C2=A0 TLS implementations SHOULD offer the applications the option to > =C2=A0 disable renegotiation completely. > > =C2=A0 To make life simpler for applications that do not expect the peer'= s > =C2=A0 certificate to change once it's been authenticated, TLS > =C2=A0 implementations may also wish to offer the applications the option > =C2=A0 abort the renegotiation if the peer tries to authenticate with a > =C2=A0 different certificate and/or different server name (in the > =C2=A0 server_name extension) than was used earlier. However, enabling > =C2=A0 this option by default for all applications could break existing > =C2=A0 applications that depend on using renegotiation to change from one > =C2=A0 certificate to another. (For example, long-lived TLS connections > =C2=A0 could change to a renewed certificate; or renegotiation could > =C2=A0 select a different cipher suite that requires using a different > =C2=A0 certificate.) I'd agree with that, if it were simply a matter of "certificate" or "server name". But, it's not. This is a matter of identity, and the identity matching rules of PKIX -- since PKIX is what defines the content and schema of the X.509 certificates presented by both pairs -- are what must control, not simply any arbitrary decision by the TLS WG. Nor can even any decision made by the TLS WG chair control. (Certificate type 0 is X.509/PKIX. Certificate type 1 is OpenPGP -- oh, but wait, we don't have anyone here to advocate the matching rules for its particular IANA assignment... Each type, 0 and 1, has different matching rules. The rule for verifying the token that is presented MUST be defined, in TLS, as the rule defined by the document that defines the format of the token, or else the TLS WG is once again putting a policy decision into a technical specification, restricting the kinds of authentication which can be used.) -Kyle H From mike-list@pobox.com Thu Dec 17 15:34: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 BA5363A69D4 for ; Thu, 17 Dec 2009 15:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr38o9D4l+xS for ; Thu, 17 Dec 2009 15:34: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 8BD283A68A9 for ; Thu, 17 Dec 2009 15:34: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 AF120A7621 for ; Thu, 17 Dec 2009 18:34: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=8ZHz6oSf2ZW7 MASpH7fmENVVnZ0=; b=LCH7L+v4OXpaEYQkAd1omF4XYhcshGAxeqOXltpCMCAb boXYRKqkmYpQQ2rNHVQXe1e/umm4KwOWyFtp9BLOsnC8Prekt4aZN6FF5VjJoMhZ uMoiOpISFQ3AHvPmF/P7EHc6a/xio8cjHx3T42TngSXkeO4aKqBPe9ewuS1ZgaY= 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=oSBjF1 6LP9XZYa49Cd00+rBd5l0yth7huBo1s6rhohKn4KTiWc09ECm8K1LoKH9SJ+CcXJ InOtNveJMjML2TFWDqOFrlBvqBk6nZ1bWmJ+pEEdQx6GUPpAW4+/CK5ThtvhC5hy /OTYa0/TGyPvFyoe1dVKpNPd69+kFIObNN+lQ= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AB776A7620 for ; Thu, 17 Dec 2009 18:34: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 239FDA761F for ; Thu, 17 Dec 2009 18:34:42 -0500 (EST) Message-ID: <4B2AC077.4010506@pobox.com> Date: Thu, 17 Dec 2009 15:36:23 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171455j4c949defu25b5ad79348197da@mail.gmail.com> In-Reply-To: <6b9359640912171455j4c949defu25b5ad79348197da@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: C11909E6-EB64-11DE-89A3-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] draft-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2009 23:35:00 -0000 Kyle Hamilton wrote: > ..... If we're going to force the implementors to > save the hashes anyway, why should we take the risk of putting them > out on the wire? (To avoid a "chosen plaintext" attack... against a > key and negotiation that's about to change?) I was going to say, "The RI data sent over the wire is protected with the same security as it was when it was in the Finished messages." But actually, that's not entirely true; the client's Finished message gets exposed on the server-to-client link in a renegotiation, where it was previously hidden (due to different keys used in both directions). Perhaps RI from server-to-client should just be the server's previous Finished message, as I believe Bodo suggested weeks ago. > (However, I do recognize that putting the prior hashes into an RI > extension will cause them to be part of the final hash for Finished > anyway, without requiring any changes in how the cryptographic system > is set up. I'm unhappy with this idea, though, because there are > still MANY extension-agnostic clients and servers out there. Clients > won't send extensions if they don't have to, and servers won't show > that they know about extensions unless the client shows exactly the > extension they expect.) Simply sending the prior hashes within RI extensions does not offer any security whatsoever. Both sides need to verify that what they receive matches what they remember from the prior handshake. This is a known problem; a peer that forgets to check is still completely vulnerable. > If those hashes are saved by each peer (as would be required under > this proposal), then it follows that since they're placed under > separate cover by the Finished message, they're an appropriate input > for the Renegotiation-Finished hash calculation. Again, there's no > reason to put them on the wire. You're right that there is no need to put it on the wire, but then you need to come up with a way to incorporate the old verify_data into the renegotiation Finished message calculation. Martin's draft suggests one way to do that, though many seem to prefer to wait until the next version of TLS to define that, since there will be lots of time to design it properly. Mike From dkg@fifthhorseman.net Thu Dec 17 15: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 24C0B3A68A9 for ; Thu, 17 Dec 2009 15:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=2.409, 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 6noXEfarDVZ1 for ; Thu, 17 Dec 2009 15:47:08 -0800 (PST) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by core3.amsl.com (Postfix) with SMTP id 1E6813A69E6 for ; Thu, 17 Dec 2009 15:47:07 -0800 (PST) Received: (qmail 33058 invoked from network); 17 Dec 2009 23:46:52 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 17 Dec 2009 23:46:52 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <4B2AC2E3.6020507@fifthhorseman.net> Date: Thu, 17 Dec 2009 18:46:43 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: tls@ietf.org References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171515t1ef6f336id71c2ee3baec5c83@mail.gmail.com> In-Reply-To: <6b9359640912171515t1ef6f336id71c2ee3baec5c83@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig10473A4838969CC66CFF7F70" Subject: [TLS] OpenPGP Certs for TLS [was: Re: Summarizing identity change discussion so far] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tls@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, 17 Dec 2009 23:47:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10473A4838969CC66CFF7F70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/17/2009 06:15 PM, Kyle Hamilton wrote: > (Certificate type 0 is X.509/PKIX. Certificate type 1 is OpenPGP -- > oh, but wait, we don't have anyone here to advocate the matching rules > for its particular IANA assignment... Each type, 0 and 1, has > different matching rules. The rule for verifying the token that is > presented MUST be defined, in TLS, as the rule defined by the document > that defines the format of the token, or else the TLS WG is once again > putting a policy decision into a technical specification, restricting > the kinds of authentication which can be used.) Actually, i'm interested in proposing some concrete matching rules for certificate type 1 (OpenPGP) at some point, though i haven't seen any attempts to formalize them yet in the context of TLS. I don't think that this particular draft (covering TLS renegotiation) is the place to do it, though. But if folks want to talk about OpenPGP certs for TLS as part of another conversation, i'm interested. I might be taking over 5081bis from Nikos Mavrogiannopoulos as well, and i'd really like feedback from the knowledgeable and experienced people here here on it. But i thought i'd let the current situation get sorted out first (and do a bit more of the background work i need to do) before moving that project up in visibility= =2E Just wanted to register that there actually *are* folks who are invested in OpenPGP certs for TLS. Btw, thanks to everyone for the thoughtful discussion here. I don't intend my sudden de-lurking as an interruption of the work at hand. Regards, --dkg --------------enig10473A4838969CC66CFF7F70 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSyrC6czS7ZTSFznpAQpe+w//WL4kPZLdYjW9HIQzvW5+8EmItobxP7Jf Rl1IpyoPwi9BgLoP5le+8+c5AIIoDxRitVhzD9XsOB0YcZmVSD7gkSvdAhQheNNT KV+F+caB+1JF1fveYAlI2JctxrXHgmSes6+vesreiI4Xl+h8K+8h9eagX3fE0HrZ wXw44dwf0yZVHYOdvGZEsRVigQbL7ZAmScQi6/8TW1RgCWjEhXtjQjJYOn8lyuAq jTWe23w8VPOqRxNJWgtpDVCVrVqZlkTlsfKnRBNkG+EfrXEk6J/EMt3MtAP/PYdB 9m+XjZOu/DLIKAAPxkZJutKCQNqQU83xiFrvln25oSpnYmKFJeMAUQmXZVUAmo1N bAvfq7OSmKmFVoJiSbihlVwqjiezBtDH2ta3ElaqofZYBkU8VLS2iBXlLsfGhaIe NiOZMB55FO1B36n94T31dTHxFVdoKnX1VuS7l2aHbeh3LHJUXvmH9Ph2EXMy93j2 TlEB9E7Gn7/07ryTBE1S2ADlyE1ajvaM5d8IuxJZMTcDToWa3mpWnL4qj0azYWbe HpvQ9+m/tzkkSKD5woa4Mz1hPjHGdMfMgNDDqFqgniANQH49ZVLSUYfhCfpvSmKu iLnnXTlikZoEIFScHEUoa/z3rYVsB5czC7cAI/y5hJYtX+JBPLkEDE47YAvDJrtj dxKx5rc3CzA= =YX5o -----END PGP SIGNATURE----- --------------enig10473A4838969CC66CFF7F70-- From mrex@sap.com Thu Dec 17 15: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 DFF053A6A09 for ; Thu, 17 Dec 2009 15:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 eTz15C5VeWdk for ; Thu, 17 Dec 2009 15:47: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 D03723A6A06 for ; Thu, 17 Dec 2009 15:47:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBHNlUL9023384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 00:47:30 +0100 (MET) From: Martin Rex Message-Id: <200912172347.nBHNlT3s026032@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 18 Dec 2009 00:47:29 +0100 (MET) In-Reply-To: <200912172145.nBHLjDUT018568@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 17, 9 10:45:13 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] Summarizing identity change discussion so far 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, 17 Dec 2009 23:47:47 -0000 Martin Rex wrote: > > Maybe we should at least mention one valid reason for why a certificate > may change in the Security Considerations: certificate update/renewal. > > There were two scenarios mentioned where this seems to be a > regular use case IIRC. Was it gaming where they were using quite > short-lived certificates and then XMPP, where they were using > quite long-lived connections? Thinking about the "valid reason" scenarios for certificate change, I'm slightly concerned about a potential disconnect between the original and the later certificates if the application designer is a little sloppy. If a design expects certificate renewal to be necessary (either short lived-certs or long-lived connections) then it is imperative that the application performs a full re-authentication when the identity changes during renegotiation. A simple certificate path validation could in some situations subvert a limited-time access restriction. Normally, you will need a specific certificate for initial authentication, because it is used for some kind of app-level logon-operation or ACL-check. When a renegotiation needs to be performed because of the expiration of the users cert, and the app does _not_ re-do the authentication logon/ACL-check, but relies blindly on the certificate path validation, then the user could simply use an entirely different certificate with a longer validity during renegotiation, succeed certificate path validation and keep using the resource beyond the expiration of the original access credential/certificate. -Martin From aerowolf@gmail.com Thu Dec 17 16:27: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 7424A3A67AF for ; Thu, 17 Dec 2009 16:27:41 -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 uwocfvKsgRuz for ; Thu, 17 Dec 2009 16:27:40 -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 4E6853A68C8 for ; Thu, 17 Dec 2009 16:27:40 -0800 (PST) Received: by pwi20 with SMTP id 20so1748701pwi.29 for ; Thu, 17 Dec 2009 16:27:20 -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=+58oWMULo7vNX2TS97Dgwlt8bhR6L4kP9fAzLBYttpg=; b=dlrW9xk+Y4SsJJmWPv6DklaW90Il2xEIISY6zkju7tPSKYHLkDFTWcyQnv4UXmv9j/ 0kBMnj98y9X78/PHYolH5jhoutf9XPQE/e17ZminrD9Aj9cxdzk7Lqz6ZrA4kwfDSC/W JCEXLSqRTz4Tunoto6TRBl67nmgNXlCe2EIs0= 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=uPEinlO5nVHHID5IfpOQQ50v/d1XiCGwVVgLVFFr2Oc7NO6PSmuXIR70x5Kr+NDP9R pIMW1PIs7oO4007a4brFlXKv7M1N1qJ3SXIofruXBmfkE4ghN/pB27M89i5kj8WSnaL9 giePSIAlFxpdwIdpPVp1Dqg8up21pNV3hZ9ZA= MIME-Version: 1.0 Received: by 10.143.20.21 with SMTP id x21mr2096393wfi.17.1261096040801; Thu, 17 Dec 2009 16:27:20 -0800 (PST) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BEE@NOK-EUMSG-01.mgdnok.nokia.com> References: <6b9359640912171335s76c04cc7o9434986d236c334b@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BEE@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 17 Dec 2009 16:27:20 -0800 Message-ID: <6b9359640912171627v16628a8g49e1644d74920644@mail.gmail.com> From: Kyle Hamilton To: Pasi.Eronen@nokia.com Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Query for consensus on an "experimental/private-use" extension identifier X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 00:27:41 -0000 On Thu, Dec 17, 2009 at 2:25 PM, wrote: > The "IETF Consensus" number allocation process is described in RFC > 2434: it means writing an Internet-Draft, and getting it published > as an IETF stream RFC (the actual allocation happens when the > draft has been approved by the IESG). Alright. I'm just asking you (in your AD hat, thus this is an "IETF Submission" under RFC2434): Is there a particular way I have to use the I-D submission tool? Or do I just write an I-D that conforms to the IETF format, upload it, and call it 'draft-hamilton-tlsext-private-allocation.txt' or something? > However, I'd like to add that often such "private use" identifiers are > intentionally designed so that they would trample over each other (so > that they only work for private use/mutually agreed experiments, and > are not used just to avoid going through the IETF process). > > If we, for example, created a "private use" extension where the first > 4 bytes are the Enterprise Number (which anyone can get just by > filling a web form), the effect would probably be pretty much the same > as changing the IANA allocation policy for the whole registry to > "First Come First Served". Nobody would be forced to either use it or act on it, and it is a viable mechanism for extensions that applications actually find themselves needing (in my case, I need to obscure both the list of CAs that the peer acting as the server will accept and the list of CAs that the peer acting as the client will accept, in a way that is noncompliant with the TLS specification). I actually have a PEN, 22232. I was thinking of making the first part of the extension be the OID, in text form, of the extension. Nobody would have to interact with one that they do not understand. (If an extension is offered by the client, and is not recognized by the server, the server doesn't send it back. The client then has the option of continuing or aborting the connection. This was all specified as part of TLSEXT, and I can't see anyone who's actually implementing a different security policy than the one I have to work with actually doing anything with the data therein (that's tagged with my policy) -- it would only be able to be used by implementations that understood it, and still be in the handshake message hash for those implementations that didn't.) The problem that exists in the the TLS WG is that it (collectively) thinks its members knows everything, every possible location where its protocol could be used, and thus every possible policy that it could possibly be wanted to run under. This leads the TLS WG to attempt to encode what they think policy should be ('an unauthenticated server MUST NOT send a ClientCertificateRequest; if it does, the client MUST terminate with a fatal handshake_error') into absolute requirements in technical documents, which is an absolute mistake. I have several ideas that would extend the range of policies that can be used in TLS -- among others, an election protocol for two peers, neither of which believing it's a server or a client -- perhaps a peer to peer protocol that says "we know how to do TLS" so that they just operate in conjunction with each other, to essentially 'draw lots' for who the server should be. I'm also playing around with an idea where a TLS-capable file descriptor is opened to a listener which immediately sends a ClientHello, not a ClientHelloRequest. I'm playing around with them (they require a modification of the handshake protocol sequence), but I do have a concrete reason why I need an extension: the definition of "acceptable CA names", as it exists in the TLS specification, cannot be changed among compliant implementations. In my case, I'm working with a bunch of peers, most of which don't want to advertise in the clear that each accepts a particular CA. Since there's no way to know which CAs a particular peer works with (the entire reason for the "acceptable CA list" in SSLv3 and TLS), this means that I need to shash all of the names of CAs that the client-cert holder has, and I need to be able to match them on the peer with the list of acceptable CAs. This is arguably the same operation as sending "what CAs I will accept" from the server to the client, and thus already belongs in the handshake hash. Since I'm trying to minimize the disruption to the protocol, this requires either an extension, or the use of an additional record type (which I'm not comfortable using, because it won't be included as part of the handshake calculation). The fact is that the working Area you are the Director of isn't really motivated to provide workable security. Each member is only motivated to provide *the best security that they themselves need*. Security is a bunch of trade-offs, and one of them is "Secure so that the cost of breaking the security is only slightly beyond the value of what is secured". In the grand scheme of things, TLS could have been made a lot more generalized, and more people beyond SMTP and HTTP would actually use it. Since the range of available extension numbers is 15-34, I can't simply ask for one for a single application. I aim for my application (and TLS implementation) to be compliant with the spec; I'm simply stuck under additional constraints/requirements that TLS can not and will not flex to accommodate. Thus, my desire is for an extension that can be used for private signalling among implementations that understand it. There isn't even a 'private use' allocation, much less a 'research' allocation. And that's just moronic. (Or maybe it isn't. Forcing entities which understand this extension to do a sanity check on the data it contains, rather than blindly accepting it, might do wonders for increasing error detection rates. Then again, my cynicism says it won't. Either way, I have a legitimate private need to be able to use an extension that otherwise doesn't exist.) I'd rather have a single extension that can have multiple semantics than a single extension for each possible semantic; because of this, it requires a means of signalling which semantic to use for it. I'd also like to see the more successful semantics break out of the private-use extension mold and into standardized semantics, while the less successful ones fade back into the primordial soup of unrealized ideas. -Kyle H From uri@ll.mit.edu Thu Dec 17 16:53: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 C06103A6A1A for ; Thu, 17 Dec 2009 16:53:27 -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 XP26qw492l31 for ; Thu, 17 Dec 2009 16:53:27 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id D10BE3A6805 for ; Thu, 17 Dec 2009 16:53:26 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBI0rBvM008014 for ; Thu, 17 Dec 2009 19:53:11 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAA6jaWlo; Thu Dec 17 19:50:35 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 17 Dec 2009 19:50:35 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Thu, 17 Dec 2009 19:50:34 -0500 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp/Z6UGtBF2gLYMQai9TLTT00qWdAAFHaTb Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854002@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 00:53:27 -0000 SSdtIGp1bXBpbmcgaW4gbGF0ZSAod2hhdCB3b3VsZCB5b3UgZXhwZWN0IGZyb20gc29tZWJvZHkg b24gdmFjYXRpb24gOi0pLCBidXQgbW9zdCBvZiB3aGF0IEkgbWF5IHdhbnQgdG8gc2F5IGlzIGFs cmVhZHkgZWxvcXVlbnRseSBwdXQgYnkgS3lsZS4gDQoNCkkgYWdyZWUgd2l0aCBoaW0gcG9pbnRz IC0gaW5jbHVkaW5nIChhbmQgZXNwZWNpYWxseSEpIHRob3NlIG1hZGUgYWJvdXQgV0cgZGVmaW5p bmcgJiBoYXJkLWNvZGluZyBpbmZsZXhpYmxlIHBvbGljaWVzIChzdGF0ZWQgaW4gc3Vic2VxdWVu dCBwb3N0aW5ncykuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxz LWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IFBhc2kuRXJvbmVu QG5va2lhLmNvbSA8UGFzaS5Fcm9uZW5Abm9raWEuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZyA8dGxz QGlldGYub3JnPg0KU2VudDogVGh1IERlYyAxNyAxNjozNzoxNSAyMDA5ClN1YmplY3Q6IFJlOiBb VExTXSBTdW1tYXJpemluZyBpZGVudGl0eSBjaGFuZ2UgZGlzY3Vzc2lvbiBzbyBmYXINCg0KT24g VHVlLCBEZWMgOCwgMjAwOSBhdCAxOjEzIEFNLCAgPFBhc2kuRXJvbmVuQG5va2lhLmNvbT4gd3Jv dGU6DQo+ICh3ZWFyaW5nIEFyZWEgRGlyZWN0b3IgaGF0KQ0KPg0KPiAtIFdlIHJlY29tbWVuZCB0 aGF0IFRMUyBsaWJyYXJpZXMgU0hPVUxEIHByb3ZpZGUgaWRlbnRpdHkgbWF0Y2hpbmcNCj4gKHdp dGggbWVtY21wLCBhYm9ydCBoYW5kc2hha2UgaWYgY2hhbmdlZCkgZnVuY3Rpb25hbGl0eSB0bw0K PiBhcHBsaWNhdGlvbnMsIGFuZCBTSE9VTEQgYWxsb3cgYXBwbGljYXRpb25zIHRvIGVuYWJsZS9k aXNhYmxlIHRoaXMNCj4gZnVuY3Rpb25hbGl0eS4NCg0KTm8sIGlkZW50aXR5IG1hdGNoaW5nIFNI T1VMRCBiZSBkb25lIGluIGFjY29yZGFuY2Ugd2l0aCBQS0lYLiAgbWVtY21wDQppcyBub3QgYXQg YWxsIHN1ZmZpY2llbnQuDQoNCkhvd2V2ZXIsIEkgd291bGQgc3VwcG9ydCB0aGUgZm9sbG93aW5n Og0KDQotIFRMUyBsaWJyYXJpZXMgU0hPVUxEIHByb3ZpZGUgaWRlbnRpdHkgbWF0Y2hpbmcgc2Vy dmljZXMgYmV0d2VlbiBhbmQNCnRocm91Z2hvdXQgcmVuZWdvdGlhdGlvbiBoYW5kc2hha2VzLiAg TGlicmFyaWVzIFNIT1VMRCBpbXBsZW1lbnQgdGhpcw0KaW4gYWNjb3JkYW5jZSB3aXRoIFBLSVgg W1BLSVhdLCBidXQgTUFZIGRvIHNvIHdpdGggYSBkaXJlY3QgbWVtb3J5DQpjb21wYXJpc29uLiAg SW1wbGVtZW50b3JzIGFyZSBjYXV0aW9uZWQgdGhhdCB0aGlzIGxhdHRlciBhcHByb2FjaCBkb2Vz DQpub3QgcHJvdmlkZSBmb3IgY2hhbmdpbmcgdGhlIGNpcGhlciBwYXJhbWV0ZXJzIC0tIHN1Y2gg YXMgYQ0KcmVuZWdvdGlhdGlvbiB3aXRoIGFuIEVDIG9yIERIIGNlcnRpZmljYXRlIGFmdGVyIGlk ZW50aWZpY2F0aW9uIHdpdGgNCmFuIFJTQSBjZXJ0aWZpY2F0ZS4gIElmIHRoZSBpZGVudGl0eSBt YXRjaGluZyBzZXJ2aWNlIGZhaWxzIHRvIG1hdGNoDQp0aGUgaWRlbnRpdHksIGltcGxlbWVudGF0 aW9ucyBNVVNUIGFib3J0IHRoZSBoYW5kc2hha2Ugd2l0aCBhIGZhdGFsDQpiYWRfY2VydGlmaWNh dGUgYWxlcnQuDQoNCi1LeWxlIEgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From uri@ll.mit.edu Thu Dec 17 16:53: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 C47723A6A25 for ; Thu, 17 Dec 2009 16:53:41 -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 7HZ7gHE5zAK6 for ; Thu, 17 Dec 2009 16:53:41 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 877EB3A6A24 for ; Thu, 17 Dec 2009 16:53:41 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBI0rQCq008115 for ; Thu, 17 Dec 2009 19:53:26 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAA6jaWlo; Thu Dec 17 19:50:35 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 17 Dec 2009 19:50:35 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Thu, 17 Dec 2009 19:50:34 -0500 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp/Z6UGtBF2gLYMQai9TLTT00qWdAAFHaTb Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854002@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 00:53:41 -0000 SSdtIGp1bXBpbmcgaW4gbGF0ZSAod2hhdCB3b3VsZCB5b3UgZXhwZWN0IGZyb20gc29tZWJvZHkg b24gdmFjYXRpb24gOi0pLCBidXQgbW9zdCBvZiB3aGF0IEkgbWF5IHdhbnQgdG8gc2F5IGlzIGFs cmVhZHkgZWxvcXVlbnRseSBwdXQgYnkgS3lsZS4gDQoNCkkgYWdyZWUgd2l0aCBoaW0gcG9pbnRz IC0gaW5jbHVkaW5nIChhbmQgZXNwZWNpYWxseSEpIHRob3NlIG1hZGUgYWJvdXQgV0cgZGVmaW5p bmcgJiBoYXJkLWNvZGluZyBpbmZsZXhpYmxlIHBvbGljaWVzIChzdGF0ZWQgaW4gc3Vic2VxdWVu dCBwb3N0aW5ncykuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxz LWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IFBhc2kuRXJvbmVu QG5va2lhLmNvbSA8UGFzaS5Fcm9uZW5Abm9raWEuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZyA8dGxz QGlldGYub3JnPg0KU2VudDogVGh1IERlYyAxNyAxNjozNzoxNSAyMDA5ClN1YmplY3Q6IFJlOiBb VExTXSBTdW1tYXJpemluZyBpZGVudGl0eSBjaGFuZ2UgZGlzY3Vzc2lvbiBzbyBmYXINCg0KT24g VHVlLCBEZWMgOCwgMjAwOSBhdCAxOjEzIEFNLCAgPFBhc2kuRXJvbmVuQG5va2lhLmNvbT4gd3Jv dGU6DQo+ICh3ZWFyaW5nIEFyZWEgRGlyZWN0b3IgaGF0KQ0KPg0KPiAtIFdlIHJlY29tbWVuZCB0 aGF0IFRMUyBsaWJyYXJpZXMgU0hPVUxEIHByb3ZpZGUgaWRlbnRpdHkgbWF0Y2hpbmcNCj4gKHdp dGggbWVtY21wLCBhYm9ydCBoYW5kc2hha2UgaWYgY2hhbmdlZCkgZnVuY3Rpb25hbGl0eSB0bw0K PiBhcHBsaWNhdGlvbnMsIGFuZCBTSE9VTEQgYWxsb3cgYXBwbGljYXRpb25zIHRvIGVuYWJsZS9k aXNhYmxlIHRoaXMNCj4gZnVuY3Rpb25hbGl0eS4NCg0KTm8sIGlkZW50aXR5IG1hdGNoaW5nIFNI T1VMRCBiZSBkb25lIGluIGFjY29yZGFuY2Ugd2l0aCBQS0lYLiAgbWVtY21wDQppcyBub3QgYXQg YWxsIHN1ZmZpY2llbnQuDQoNCkhvd2V2ZXIsIEkgd291bGQgc3VwcG9ydCB0aGUgZm9sbG93aW5n Og0KDQotIFRMUyBsaWJyYXJpZXMgU0hPVUxEIHByb3ZpZGUgaWRlbnRpdHkgbWF0Y2hpbmcgc2Vy dmljZXMgYmV0d2VlbiBhbmQNCnRocm91Z2hvdXQgcmVuZWdvdGlhdGlvbiBoYW5kc2hha2VzLiAg TGlicmFyaWVzIFNIT1VMRCBpbXBsZW1lbnQgdGhpcw0KaW4gYWNjb3JkYW5jZSB3aXRoIFBLSVgg W1BLSVhdLCBidXQgTUFZIGRvIHNvIHdpdGggYSBkaXJlY3QgbWVtb3J5DQpjb21wYXJpc29uLiAg SW1wbGVtZW50b3JzIGFyZSBjYXV0aW9uZWQgdGhhdCB0aGlzIGxhdHRlciBhcHByb2FjaCBkb2Vz DQpub3QgcHJvdmlkZSBmb3IgY2hhbmdpbmcgdGhlIGNpcGhlciBwYXJhbWV0ZXJzIC0tIHN1Y2gg YXMgYQ0KcmVuZWdvdGlhdGlvbiB3aXRoIGFuIEVDIG9yIERIIGNlcnRpZmljYXRlIGFmdGVyIGlk ZW50aWZpY2F0aW9uIHdpdGgNCmFuIFJTQSBjZXJ0aWZpY2F0ZS4gIElmIHRoZSBpZGVudGl0eSBt YXRjaGluZyBzZXJ2aWNlIGZhaWxzIHRvIG1hdGNoDQp0aGUgaWRlbnRpdHksIGltcGxlbWVudGF0 aW9ucyBNVVNUIGFib3J0IHRoZSBoYW5kc2hha2Ugd2l0aCBhIGZhdGFsDQpiYWRfY2VydGlmaWNh dGUgYWxlcnQuDQoNCi1LeWxlIEgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= From aerowolf@gmail.com Thu Dec 17 17:15: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 592B43A69EA for ; Thu, 17 Dec 2009 17:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 r0dHOZzvqjD1 for ; Thu, 17 Dec 2009 17:15:47 -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 8827E3A67A1 for ; Thu, 17 Dec 2009 17:15:47 -0800 (PST) Received: by pzk6 with SMTP id 6so1866397pzk.29 for ; Thu, 17 Dec 2009 17:15:30 -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=588WEU9dnbmwkAgI/b7cKuuooS5v2yq6dIW/u6N+2wc=; b=D9sm0gCtbFU4//rMHGTBlJChOVQV1o17HU4PsVnI9YGV2wQHr9qrg+xZ+ttxbQVo83 FtHQU9jkalfAmbhWY//KV+MQ75JX5xuvHJcIKYYvVe+FxNo2CZTIiaLbhAg0zbfJ6A69 9b1+ZGB6DDK7BaIWuqFUPBxCAVkBpbO4KykGw= 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=m2Xayvp1PqvKmbv0WGGXV0LT1PQA5INshLL74V6hKgIYIH4veC4uVSn9VAedqNvKR/ t87fkg4DGUrK+AyfNXhDquoFrgE6NpiRFyH0Y06979jKZj8h2GRZwFamrHdvK9rBlKd6 ZqUK8SPsGjDRZB3xyXb7pL8RwGFu1mhLLb+mg= MIME-Version: 1.0 Received: by 10.142.5.30 with SMTP id 30mr2159901wfe.115.1261098930722; Thu, 17 Dec 2009 17:15:30 -0800 (PST) In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854002@LLE2K7-BE01.mitll.ad.local> References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854002@LLE2K7-BE01.mitll.ad.local> Date: Thu, 17 Dec 2009 17:15:30 -0800 Message-ID: <6b9359640912171715p75ad2266y2a07f057ed8a7b63@mail.gmail.com> From: Kyle Hamilton To: "Blumenthal, Uri - 0662 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 01:15:48 -0000 I'll just state this: I believe that defining the semantics of identity credentials provided during the course of the TLS protocol's execution is NOT within the legitimate realm of the design of the TLS protocol. TLS explicitly references PKIX, and PKIX is really the only place that uses 'identity', but (on further reading) it doesn't describe precisely what 'identity' is. So, I'll take a stab at a potential guidance for those who don't have the time to research in-depth, taking into account Pasi's and everyone's ideas: If there is a match between ANY one of the new certificate's Subject/sAN and the old certificate's Subject/sAN, including all path components in the same order for that entity, AND is issued by the same authority, it SHOULD be regarded as being the same identity, though exceptions will undoubtedly exist. Differences in the Certificate Policy, kU, or eKU fields SHOULD be evaluated as well, to ensure that the new certificate is valid for the kind of connection and transactions being performed. The only thing that SHOULD modify the default behavior (defined as "all 'MUST*' and 'SHOULD*' but no 'MAY*'") is the implementation of a security policy. If such a security policy exists but has no information on this topic, the defaults SHOULD control (unless there's a very, very good reason not to). -Kyle H On Thu, Dec 17, 2009 at 4:50 PM, Blumenthal, Uri - 0662 - MITLL wrote: > I'm jumping in late (what would you expect from somebody on vacation :-),= but most of what I may want to say is already eloquently put by Kyle. > > I agree with him points - including (and especially!) those made about WG= defining & hard-coding inflexible policies (stated in subsequent postings)= . > > > ----- Original Message ----- > From: tls-bounces@ietf.org > To: Pasi.Eronen@nokia.com > Cc: tls@ietf.org > Sent: Thu Dec 17 16:37:15 2009 > Subject: Re: [TLS] Summarizing identity change discussion so far > > On Tue, Dec 8, 2009 at 1:13 AM, =C2=A0 wrote: >> (wearing Area Director hat) >> >> - We recommend that TLS libraries SHOULD provide identity matching >> (with memcmp, abort handshake if changed) functionality to >> applications, and SHOULD allow applications to enable/disable this >> functionality. > > No, identity matching SHOULD be done in accordance with PKIX. =C2=A0memcm= p > is not at all sufficient. > > However, I would support the following: > > - TLS libraries SHOULD provide identity matching services between and > throughout renegotiation handshakes. =C2=A0Libraries SHOULD implement thi= s > in accordance with PKIX [PKIX], but MAY do so with a direct memory > comparison. =C2=A0Implementors are cautioned that this latter approach do= es > not provide for changing the cipher parameters -- such as a > renegotiation with an EC or DH certificate after identification with > an RSA certificate. =C2=A0If the identity matching service fails to match > the identity, implementations MUST abort the handshake with a fatal > bad_certificate alert. > > -Kyle H > _______________________________________________ > 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 Thu Dec 17 17:31: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 8D5913A680D for ; Thu, 17 Dec 2009 17:31:31 -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 02wz9w6c0wC1 for ; Thu, 17 Dec 2009 17:31: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 722ED3A67B5 for ; Thu, 17 Dec 2009 17:31:30 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBI1VDYW014595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 02:31:13 +0100 (MET) From: Martin Rex Message-Id: <200912180131.nBI1VCoS002680@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Fri, 18 Dec 2009 02:31:12 +0100 (MET) In-Reply-To: <6b9359640912171715p75ad2266y2a07f057ed8a7b63@mail.gmail.com> from "Kyle Hamilton" at Dec 17, 9 05:15:30 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] Summarizing identity change discussion so far 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, 18 Dec 2009 01:31:31 -0000 Kyle Hamilton wrote: > > I'll just state this: I believe that defining the semantics of > identity credentials provided during the course of the TLS protocol's > execution is NOT within the legitimate realm of the design of the TLS > protocol. TLS explicitly references PKIX, and PKIX is really the only > place that uses 'identity', but (on further reading) it doesn't > describe precisely what 'identity' is. > > So, I'll take a stab at a potential guidance for those who don't have > the time to research in-depth, taking into account Pasi's and > everyone's ideas: If there is a match between ANY one of the new > certificate's Subject/sAN and the old certificate's Subject/sAN, > including all path components in the same order for that entity, AND > is issued by the same authority, it SHOULD be regarded as being the > same identity, though exceptions will undoubtedly exist. Differences > in the Certificate Policy, kU, or eKU fields SHOULD be evaluated as > well, to ensure that the new certificate is valid for the kind of > connection and transactions being performed. *I* would really prefer that a TLS spec does _NOT_ open that can of worms called X.509 Certificate at all. You don't know how many trust anchors there are (some software comes preloaded with more than one hundred) and you don't know how long the CA hierarchies are and whether those trust anchors all have path length limits. If you only look at Subject/sAN, you can be fooled with certs from different CAs, and if add the issuer of the end-entity cert, then you can be fooled if your attacker can obtain a specific intermediate CA cert under some other root, and on and on. I also see absolutely no reason to duplicate code and functionality here that may get out of sync all too easily. The application was able to perform the initial authentication (log-on or ACL-check), so it is the duty of the application to perform any reauthentication in the very same fashion when renegotiation results in a different cert(chain). Everything else will result in endless pain. ...and that is a reason why personally, I prefer that the necessity for cert renewal requires a new connection and full initial handshake-- because that is exaclty the code path which has all of the functionality and checks that we are looking for! -Martin From aerowolf@gmail.com Thu Dec 17 17:45: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 8AEF43A6860 for ; Thu, 17 Dec 2009 17:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyBVS+sltIbG for ; Thu, 17 Dec 2009 17:45:55 -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 C8A083A6824 for ; Thu, 17 Dec 2009 17:45:55 -0800 (PST) Received: by pzk6 with SMTP id 6so1879368pzk.29 for ; Thu, 17 Dec 2009 17:45:39 -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=wGPEAoXI2m2URhQ3MixnviIxhdlP30Cz72XQSL2RHXc=; b=ha/QKL14jebvwItSKxG9V7RcFcAKD+vzQ/qnnWZooFvKIykgi4uzSTUFtCZ7E0nkAb bRvE71keFT5VHhc8R4aloHtAgsB37Is30oNMyTFmETfwD3DgzUOOKshMtbgFPYEzkXPu FsVO9lqAfV7ABKR7vlk9X4c0AK6MuSUm2Ug3g= 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=cEX6Dzflg9j/V+H6zCDLqwosCiU2uS1zvUEM4ntUBTZpF18N564eFqOXA6H+r5L5j1 DIWzvkcL+xDAkVnPwq50Lb3NrxI9bLB6L1KEJ9fnuWlrmLZW2vXwvJiWJx7hxGPHhefO 3n5WoA1UfW2IF8M3Ioyuepu6mUV8f1y9sZ1rY= MIME-Version: 1.0 Received: by 10.143.27.31 with SMTP id e31mr2135527wfj.173.1261100738964; Thu, 17 Dec 2009 17:45:38 -0800 (PST) In-Reply-To: <200912180131.nBI1VCoS002680@fs4113.wdf.sap.corp> References: <6b9359640912171715p75ad2266y2a07f057ed8a7b63@mail.gmail.com> <200912180131.nBI1VCoS002680@fs4113.wdf.sap.corp> Date: Thu, 17 Dec 2009 17:45:38 -0800 Message-ID: <6b9359640912171745k3be3d9a9je84a449fd998dab0@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 01:45:56 -0000 On Thu, Dec 17, 2009 at 5:31 PM, Martin Rex wrote: > The application was able to perform the initial authentication > (log-on or ACL-check), so it is the duty of the application to > perform any reauthentication in the very same fashion when > renegotiation results in a different cert(chain). =C2=A0Everything > else will result in endless pain. > > > ...and that is a reason why personally, I prefer that the necessity > for cert renewal requires a new connection and full initial handshake-- > because that is exaclty the code path which has all of the > functionality and checks that we are looking for! I do agree with you there. Unless the saved session mechanism also triggers the functionality and checks that a full handshake would, but I think that's too much to hope for. -Kyle H From djhopwood@googlemail.com Thu Dec 17 18: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 CD2C83A6970 for ; Thu, 17 Dec 2009 18:23: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 wasNruXdlhYE for ; Thu, 17 Dec 2009 18:23:53 -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 89EDF3A6874 for ; Thu, 17 Dec 2009 18:23:53 -0800 (PST) Received: by ewy6 with SMTP id 6so20433ewy.29 for ; Thu, 17 Dec 2009 18:23: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=MK2k8DAL09d9aUar2v/VK0gfrarYBFS+Pf1cKXNqhBA=; b=XRO/CfmUTrLJCXrVfdo1HTBxQUQsGGmP2C21W/0fAadoKrVM96EBAyaJle7QsXuLWE 82dFAQoPQ/VB9xpQL2vmmj6RllqKrY/JpX/7KB6G3j9HQU37zjzBPz6FXZMQDkIGs8Eq WhsGz7ay3TvlE8REIRAwNbjnLPKn5nEg9vY2I= 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=VaNnkYoPpV+COhiHDbA9c+T3zMnWJ1NBSRsXN+KN61L8gbhkwqMUQsoGrd7CFrtPV7 TZt1w2foH8DxfKFAWV/9Bsx8GZ1YffaepvoQpZOJUl9naTjjFpYMzqhDStSYi5fU2zBZ 6UsQjXc0hB/N0RfUUyytmp0MQ8ojJe4uScy/0= Received: by 10.213.46.148 with SMTP id j20mr3982846ebf.1.1261103014852; Thu, 17 Dec 2009 18:23:34 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 14sm1649759ewy.11.2009.12.17.18.23.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 18:23:33 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2AE782.2090002@jacaranda.org> Date: Fri, 18 Dec 2009 02:22: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: <3561bdcc0912161417j6cdcfe59l1be2131c9ec27da0@mail.gmail.com> <4B296275.8010108@extendedsubset.com> <4B29A4A4.1090106@jacaranda.org> <6b9359640912171242j73857862n132649c45a25e9d7@mail.gmail.com> In-Reply-To: <6b9359640912171242j73857862n132649c45a25e9d7@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBF06AD78420F1AD38B6AA3A7" Subject: Re: [TLS] Third Option? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 02:23:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBF06AD78420F1AD38B6AA3A7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kyle Hamilton wrote: > On Wed, Dec 16, 2009 at 7:25 PM, David-Sarah Hopwood > wrote: >>> In short, everyone* needs to patch and disable compatible/insecure mo= de >>> as soon as is practical. >>> >>> *Except those who can prove that their endpoint cannot renegotiate an= d >>> will never be willing to talk to a server that can possibly renegotia= te. >> >> No, even those. >> >> If any server does not patch, it will soon fail to be interoperable wi= th >> clients that require patched servers. >=20 > And if the patches to the server include patches that are not desired > by the entity running the server? Then they have at least five options: - be non-interoperable; - try to get a backport of just the renegotiation patch from the server implementors; - do such a backport, or commission one, if the server code is available= ; - patch anyway; - switch to a different server. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigBF06AD78420F1AD38B6AA3A7 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/ iF4EAREIAAYFAksq54kACgkQWUc8YzyzqAdIfAD8DeMEXXLCKQ7Urmq8Na0gTdYH 1i2l9c69twJtHZWTb9QA/iVyDhADFAi8VxccaE5Z3n7ml+BPM0F6jho1/9c91KGI =Gu++ -----END PGP SIGNATURE----- --------------enigBF06AD78420F1AD38B6AA3A7-- From stpeter@stpeter.im Thu Dec 17 18: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 79E083A6828 for ; Thu, 17 Dec 2009 18:49: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=[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 TjzQ8RiTMNiS for ; Thu, 17 Dec 2009 18:49:43 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6F1AD3A67A8 for ; Thu, 17 Dec 2009 18:49:43 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2789A40332; Thu, 17 Dec 2009 19:49:28 -0700 (MST) Message-ID: <4B2AEDB7.10500@stpeter.im> Date: Thu, 17 Dec 2009 19:49:27 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912172145.nBHLjDUT018568@fs4113.wdf.sap.corp> In-Reply-To: <200912172145.nBHLjDUT018568@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="------------ms030203090503040703000106" Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 02:49:44 -0000 This is a cryptographically signed message in MIME format. --------------ms030203090503040703000106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/17/09 2:45 PM, Martin Rex wrote: > There were two scenarios mentioned where this seems to be a > regular use case IIRC. Was it gaming where they were using quite > short-lived certificates and then XMPP, where they were using > quite long-lived connections? Correct, in XMPP we have long-lived connections, where by "long-lived" we mean connections that might be up for days or weeks or months. We recently worked to clarify the handling of certificates in the context of such connections (section 14.2.2.3 of draft-ietf-xmpp-3920bis-04). Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030203090503040703000106 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 hvcNAQkFMQ8XDTA5MTIxODAyNDkyN1owIwYJKoZIhvcNAQkEMRYEFHt5OAEPuxrtBcpMDOTZ v+x6VyHhMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAHZr4R1GQbWbmoJSwFse0TRZ2M60FfLGgV7cAr5XU lfs3dKjfg8066zJxV97BSaqQhyNGRjEzKru9DABi5OEc7ySJdLUxaa+uH8n2LISSQL85FKPa C3UgSdugygtQy4p2Wy7Wn5+xCMiVuYeEWffXdH/gqLEkEt+3beCGWsai4hmGNu+NbDyShayu +ydQsjXkfhMz313Lr+aT8aELwsGty4oHBL9pGcaR88PYQXrZkCjx98/va1tS+qx+nNuU5cAg cQLbXZpD4FXSwr8X2OM4MNpaurccHqqMLE/uuT4YYUNY7HNt4wl3vhbXc0cmyIXjrHSq3WcR ILS2P3rCqXF9IgAAAAAAAA== --------------ms030203090503040703000106-- From stpeter@stpeter.im Thu Dec 17 18: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 57DF13A6A1B for ; Thu, 17 Dec 2009 18: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 rfUq9P8Ke4JJ for ; Thu, 17 Dec 2009 18:50:37 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3C1B33A68B8 for ; Thu, 17 Dec 2009 18:50:37 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1057240332; Thu, 17 Dec 2009 19:50:21 -0700 (MST) Message-ID: <4B2AEDEE.30007@stpeter.im> Date: Thu, 17 Dec 2009 19:50:22 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Michael Gray References: In-Reply-To: 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="------------ms060200040708070905070600" Cc: tls@ietf.org, Kyle Hamilton Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 02:50:38 -0000 This is a cryptographically signed message in MIME format. --------------ms060200040708070905070600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/17/09 3:39 PM, Michael Gray wrote: > mrex@sap.com wrote: > >> Kyle Hamilton wrote: >>> On Tue, Dec 8, 2009 at 1:13 AM, wrote: >>>> (wearing Area Director hat) >>>> >>>> - We recommend that TLS libraries SHOULD provide identity matching >>>> (with memcmp, abort handshake if changed) functionality to >>>> applications, and SHOULD allow applications to enable/disable this >>>> functionality. >>> No, identity matching SHOULD be done in accordance with PKIX. memcmp >>> is not at all sufficient. >>> >>> However, I would support the following: >>> >>> - TLS libraries SHOULD provide identity matching services between and >>> throughout renegotiation handshakes. Libraries SHOULD implement this >>> in accordance with PKIX [PKIX], but MAY do so with a direct memory >>> comparison. Implementors are cautioned that this latter approach does >>> not provide for changing the cipher parameters -- such as a >>> renegotiation with an EC or DH certificate after identification with >>> an RSA certificate. If the identity matching service fails to match >>> the identity, implementations MUST abort the handshake with a fatal >>> bad_certificate alert. >> The way the TLS specifications are currently archtected, this is >> a service that is _not_ available from TLS. >> >> Although there is likely some PKI(X)-Software available to the >> TLS implementation for the X.509 stuff and certificate path validation >> processing, but it can easily be that it is a completely different >> module. >> >> If an application currently wants to look at the contents of >> the certificates exchanged and authenticated during the TLS handshake, >> then this is explicitly declared out-of-scope for TLS in the base spec >> (RFC-5246, section 1. last paragraph). I would strongly recommend >> to leave the code slicing (modularization) between application, >> PKI-Software and TLS-implementation outside the scope of this spec. > > Yes the problem is defining what an identity change is precisely. We know > that CA's load all sorts of stuff in to certificates as part of the DN etc > and the same identify could have multiple certificates, and could be > identified by multiple CAs. If we say that in TLS we are going to check > identity then it has to be very precisely defined, or extremely vaguely > defined so that the implementation can not be accused of non compliance or > invalid/suspect identity matching. Perhaps it needs to be a vague as > possible so that TLS implementation can simply push it back to the > application layer in practice As previously expressed, I think this belongs at the application layer. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060200040708070905070600 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 hvcNAQkFMQ8XDTA5MTIxODAyNTAyMlowIwYJKoZIhvcNAQkEMRYEFDphGqVX2FOnR+ea1eXx TkZ0TFflMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASBaw+yKm3DX5QaN6uy17iLik6dhueu5XVhNC3K/e 43Q0ZYL6J+CXkOqhnPu/bIGoWtk3bM4IpVAD1SajjpERPCjNrBywdYlan+I9fr0QWIcIXfUa pLdlZz4vi7Uhkeh4tJzbwBXeWiOOC1W53syDEQmFgFxq0BZLUXlk0aAiStMYserdfNPd9LYd /0bkE4NOLhhM4Cp60AFIyRexnp0Y/wkiKyq3hSuNHK41ePCMsyAO8ExqLkLxhhyUPm64qSSB TO7w0x7EslZiwi2uZfgjPNukEJ41PVEyKQ505qZ0NWLQ8GkA5iLuHmAYCDDVvoiJ8ixydzBW /FEHlieHE0ofOgAAAAAAAA== --------------ms060200040708070905070600-- From stpeter@stpeter.im Thu Dec 17 18:54: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 4C6323A6A26 for ; Thu, 17 Dec 2009 18:54: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 de8R1J5CW26V for ; Thu, 17 Dec 2009 18:54:38 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5C48D3A68B8 for ; Thu, 17 Dec 2009 18:54:38 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 63B6F40332; Thu, 17 Dec 2009 19:54:23 -0700 (MST) Message-ID: <4B2AEEDE.1040402@stpeter.im> Date: Thu, 17 Dec 2009 19:54:22 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912172347.nBHNlT3s026032@fs4113.wdf.sap.corp> In-Reply-To: <200912172347.nBHNlT3s026032@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="------------ms060904060305050008000704" Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 02:54:39 -0000 This is a cryptographically signed message in MIME format. --------------ms060904060305050008000704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/17/09 4:47 PM, Martin Rex wrote: > If a design expects certificate renewal to be necessary > (either short lived-certs or long-lived connections) then it is > imperative that the application performs a full re-authentication > when the identity changes during renegotiation. Agreed. FWIW, our text about this in draft-ietf-xmpp-3920bis currently reads as follows (this does not yet talk about identity changes, so we'll need to address that case as well -- e.g., the certificate might have been replaced by a new one before the old one expired, but the data in the cert might be different): ### 14.2.2.3. Checking of Certificates in Long-Lived Streams Because XMPP uses long-lived XML streams, it is possible that a certificate presented during stream negotiation might expire or be revoked while the stream is still live (this is especially relevant in the context of server-to-server streams). Therefore, each party to a long-lived stream SHOULD: 1. Cache the expiration date of the certificate presented by the other party and any certificates on which that certificate depends (such as a root or intermediate certificate for a certification authority), and terminate the stream when any such certificate expires. 2. Periodically query the Online Certificate Status Protocol [OCSP] responder listed in the Authority Information Access (AIA) extension of the certificate presented by the other party and any certificates on which that certificate depends (such as a root or intermediate certificate for a certification authority), and terminate the stream if any such certificate has been revoked. ### /psa --------------ms060904060305050008000704 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 hvcNAQkFMQ8XDTA5MTIxODAyNTQyMlowIwYJKoZIhvcNAQkEMRYEFEJCD7EAMcj37RZv5sW8 Wa573zqjMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAXkwtEekRWuG4TYeWhsDFbf3EUGSpxwW/Lr2dW5YO Xil1B55iX+BnXdDiUBIqwF5/xdB+b8AT0xV03//RhAZJWIAneyF1T1Z/G6a+flVZXAO4ojFW VXm1YRSg8lyTmNSN9UwUtl4OM5k7oZJzIfn4uTqlofOLPOUB40ydT91pOUZbx0aqOMmMErHd 5l+H9czFJphQQo6dq3cbYItN3Onno76186nNnUMwFczEh5yg7dunHZjoPlyoVe9fMhhjwbot QLJLi3P6CDo+IrAoFzNauRE6a8F4OoLZpQ1+qiS5Okax0rei/Fg1G8Gfg+ZsLi84wZ9yPn8v BFw6f1X2T/wGDAAAAAAAAA== --------------ms060904060305050008000704-- From stpeter@stpeter.im Thu Dec 17 18: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 75C753A687F for ; Thu, 17 Dec 2009 18:59: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 zBXGVGUJhGK4 for ; Thu, 17 Dec 2009 18:59:10 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 012143A63D3 for ; Thu, 17 Dec 2009 18:59:09 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B119F40332; Thu, 17 Dec 2009 19:58:54 -0700 (MST) Message-ID: <4B2AEFED.207@stpeter.im> Date: Thu, 17 Dec 2009 19:58:53 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Kyle Hamilton References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854002@LLE2K7-BE01.mitll.ad.local> <6b9359640912171715p75ad2266y2a07f057ed8a7b63@mail.gmail.com> In-Reply-To: <6b9359640912171715p75ad2266y2a07f057ed8a7b63@mail.gmail.com> 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="------------ms000908030804060402050308" Cc: "tls@ietf.org" Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 02:59:11 -0000 This is a cryptographically signed message in MIME format. --------------ms000908030804060402050308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/17/09 6:15 PM, Kyle Hamilton wrote: > I'll just state this: I believe that defining the semantics of > identity credentials provided during the course of the TLS protocol's > execution is NOT within the legitimate realm of the design of the TLS > protocol. TLS explicitly references PKIX, and PKIX is really the only > place that uses 'identity', but (on further reading) it doesn't > describe precisely what 'identity' is. > > So, I'll take a stab at a potential guidance for those who don't have > the time to research in-depth, taking into account Pasi's and > everyone's ideas: If there is a match between ANY one of the new > certificate's Subject/sAN and the old certificate's Subject/sAN, > including all path components in the same order for that entity, AND > is issued by the same authority, it SHOULD be regarded as being the > same identity, though exceptions will undoubtedly exist. Differences > in the Certificate Policy, kU, or eKU fields SHOULD be evaluated as > well, to ensure that the new certificate is valid for the kind of > connection and transactions being performed. For an attempt at in-depth guidance about the checking of identities in certificates presented within application protocols that use TLS, see: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02 I hope to push out -03 in the next week, incorporating feedback received at IETF 76. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000908030804060402050308 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 hvcNAQkFMQ8XDTA5MTIxODAyNTg1M1owIwYJKoZIhvcNAQkEMRYEFIZ4InzSO8R8gIgiNICO pugmE3akMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAgcnFiazIqIt29y+RlaMYUKTZClTL4qPf/X6P9Scl FzH84fqvNjnwuU2Iixthz0jDfv6JJkbQ1o1clv/p0JOLwmlx48TuTHtjgMyWiXAdVM2ahxfj OEZ0CaQmllSTvjOAGRVWhdKKqYatH1HwlvevhC9lsiKer1qCZrx1DTs4zEfQ2sdiqLSvR5fN O+LEoILAX3rGFqCSulr4ZuZJRncXG5IVbggJ49tS1DO4E1fa8G/K+LZo5ddVDKZCi7ihXRqD yIP7JfqHZI81aWp6DjamtRyJQRQffrgdjGjAN/Tl3wWLu5SW/VWbtggca9vt+MlqKiiLNez4 RD7cubzb58xTEQAAAAAAAA== --------------ms000908030804060402050308-- From djhopwood@googlemail.com Thu Dec 17 21: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 79D103A68D2 for ; Thu, 17 Dec 2009 21:26: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 OIN1NF44APnZ for ; Thu, 17 Dec 2009 21:26:54 -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 AC4D93A6887 for ; Thu, 17 Dec 2009 21:26:53 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so734865eyd.51 for ; Thu, 17 Dec 2009 21:26: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=ZzqDfdEILsl1hnTUJvi8R3QZOAoiA7MOJBBsmzv9tAg=; b=Pdm6yKcxEQjAxHvq5cH4zMCwQuochIAps/id2DTHAzSQUK9OmItvgcz+N6r2Dqww+6 0v8p/+t/8OTpr9WFCYXG79ylMHuufzdcnYAd1iQMPQaoFr4EGv5xiKUAAyfFa+VK8CV8 QsBPzzjG1etUtMtWeNKEmeUzmNYU/OrpToBxc= 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=syWeqLbx1nklul+3YAYoFZxCfvMo8u9Id0oK2bCTgF1fQyYcJlUKA59RIcuF0E6KLf D4BQtXq8kXMmWkHdwLo31U6L9lBaSFkjCGtcsZkQVeAd6Qzcq3rbsALZnDRA5EavQtI1 EQ73FtpWXKzoBHx5PLPW7j26gPcE9PFYD9Krc= Received: by 10.213.50.69 with SMTP id y5mr4029196ebf.48.1261113995983; Thu, 17 Dec 2009 21:26:35 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 13sm1712402ewy.1.2009.12.17.21.26.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 21:26:34 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2B124E.3030907@jacaranda.org> Date: Fri, 18 Dec 2009 05:25:34 +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: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp> <808FD6E27AD4884E94820BC333B2DB774F31F777D1@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171455j4c949defu25b5ad79348197da@mail.gmail.com> In-Reply-To: <6b9359640912171455j4c949defu25b5ad79348197da@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFF7D68A4638108FFE67DC10A" Subject: Re: [TLS] draft-ietf-tls-renegotation: next X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 05:26:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF7D68A4638108FFE67DC10A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kyle Hamilton wrote: > Also, it is illegal for any TLS implementation to negotiate > NULL-NULL-NULL, and it is illegal for any TLS implementation to > transmit application data after the initial handshake has been > initiated and before the Finished messages have been generated by both > sides. >=20 > This would suggest that another mitigation for this attack would be to > include a zero-length application-data packet in all renegotiations; > if one side thinks it's an initial negotiation, and it receives an > application data packet under the state that it thinks is > NULL-NULL-NULL, it is required that it close the connection with a > fatal handshake_failure alert. >=20 > (The only problem with this potential mitigation is that if the client > is connected to the MITM, and the MITM is connected to the server, the > MITM could simply strip out the zero-length application-data chunk, > since TLS relies on underlying mechanisms to verify that it has a > two-way error-detected/corrected clear channel -- TCP/IP, SPX/IPX, a > clean serial line, or an MNP5 modem. TLS doesn't try to detect lost > chunks from the server.) Unfortunately, this problem is a fatal objection to what was otherwise a very interesting idea: - If the extra record is sent before the ChangeCipherSpec of a renegotiating handshake, then the attacker can strip it out (because it won't be included in the handshake_messages, and it doesn't affect the sequence number of messages after the ChangeCipherSpec, which resets the sequence number to zero). - If the extra record is sent after the ChangeCipherSpec but before the Finished message, then (by my reading) the receiving peer MUST treat this as a fatal error regardless of whether it believed the handshake was initial or renegotiating. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigFF7D68A4638108FFE67DC10A 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/ iF4EAREIAAYFAksrElUACgkQWUc8YzyzqAeCXwD8CYbnJBCTPJEv9aeTDqVBDPSo /fDgKhp05njIDJ4fxK8A/28oH7qaDvs8Oj8CDVgdZtMIIfCbBR7L/kQco1rDTVoP =NcG0 -----END PGP SIGNATURE----- --------------enigFF7D68A4638108FFE67DC10A-- From djhopwood@googlemail.com Thu Dec 17 21:48: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 A15713A6A30 for ; Thu, 17 Dec 2009 21:48: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 r-ucfUkWDqYX for ; Thu, 17 Dec 2009 21:48: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 17E1F3A68D4 for ; Thu, 17 Dec 2009 21:48:49 -0800 (PST) Received: by ewy6 with SMTP id 6so104305ewy.29 for ; Thu, 17 Dec 2009 21:48: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=4Zw3TJm7Qk0vDMQoFdEbYeUL8fzdzk18zZ0rG8AmaqY=; b=p4do5AstDiOy/ydHG2DLvVICjFOoUOLoZfLyp8HoAZRJaV0oRpBCj5ZFCH8igg5/V7 rXe+vyyk7mioxg1dEGosrIijcTyl8OnnRMFOlWNZKfx1ChpY53nOdIrOhC9gSam0h6Nc q1vYKiCgjtWrQp+Cr58rr2pnZXqnTbSd/xRsI= 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=PNmfh6A00K0jjj0Qvka8gnIHb0fVS8XFDrNnenvGQWerunD09nYYCGBlA+umiCbAod uO75EG2KntX+ZhG6/2VEFVSBkc8iCc5lGSykacUocgyl9fjb2fRbWvrt9ngyNQ/KDQdA 5Z4mdwqb/AdLMnkRWgsfY1B+m8E1o3M+v0okw= Received: by 10.213.43.195 with SMTP id x3mr9954400ebe.19.1261115311977; Thu, 17 Dec 2009 21:48:31 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 14sm1710026ewy.15.2009.12.17.21.48.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 21:48:31 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2B1770.3090004@jacaranda.org> Date: Fri, 18 Dec 2009 05:47:28 +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: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> In-Reply-To: <6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig6275D907DFDE3C3E5956664D" Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 05:48:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6275D907DFDE3C3E5956664D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kyle Hamilton wrote: > On Tue, Dec 8, 2009 at 1:13 AM, wrote: >> (wearing Area Director hat) >> >> - We recommend that TLS libraries SHOULD provide identity matching >> (with memcmp, abort handshake if changed) functionality to >> applications, and SHOULD allow applications to enable/disable this >> functionality. >=20 > No, identity matching SHOULD be done in accordance with PKIX. Strongly disagree. If implementations try to do identity matching that is any more complicated than memcmp then they *will* get it wrong; see for evidence. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig6275D907DFDE3C3E5956664D 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/ iF4EAREIAAYFAksrF3YACgkQWUc8YzyzqAcAYQD/SuBDcZRr7T6aW4xX1+8tRgrw Q5kdNBQQEdb+OGmTWs4A/3n6TqTJE6bIL6BduxRQvsQebxnFqPKQXtyMlYtK0u9U =lcOF -----END PGP SIGNATURE----- --------------enig6275D907DFDE3C3E5956664D-- From uri@ll.mit.edu Thu Dec 17 22:08: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 AA3E13A6938 for ; Thu, 17 Dec 2009 22:08:42 -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 eezZXP6OYzW2 for ; Thu, 17 Dec 2009 22:08:41 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 870713A685E for ; Thu, 17 Dec 2009 22:08:41 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBI68PPD025435; Fri, 18 Dec 2009 01:08:25 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAABna4vW; Fri Dec 18 01:05:59 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Fri, 18 Dec 2009 01:05:59 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'david-sarah@jacaranda.org'" , "'tls@ietf.org'" Date: Fri, 18 Dec 2009 01:05:58 -0500 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp/pcHRqt5rlWUUT9yFZqadejy2HQAAmlV2 Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854006@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 06:08:42 -0000 TXkgc3Ryb25nIGNvbnZpY3Rpb24gaXMgdGhhdCB0aGUgZmFjdCBvZiBub24temVybyBwcm9iYWJp bGl0eSB0byBnZXQgIChlLmcuKSBQS0lYIGlkZW50aXR5IG1hdGNoaW5nIHdyb25nIC0gZG9lcyBO T1QgaW52YWxpZGF0ZSB0aGUgbmVlZCBmb3Igc29tZXRoaW5nIG1vcmUgcG93ZXJmdWwgYW5kIHVz YWJsZSB0aGFuIG1lbWNtcC4gSSdtIG5vdCBjb252aW5jZWQgdGhhdCBNRDUgY29sbGlzaW9uIGV4 cGxvaXRhdGlvbiBqdXN0aWZpZXMgcmVzdHJpY3Rpb24gb2YgbWF0Y2hpbmcgdG8gbWVtY21wLg0K DQpBZ2FpbiwgbXkgc3Ryb25nIGNvbnZpY3Rpb24uDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3Jn Pg0KVG86IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYub3JnPg0KU2VudDogRnJpIERlYyAxOCAwMDo0 NzoyOCAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBTdW1tYXJpemluZyBpZGVudGl0eSBjaGFuZ2Ug ZGlzY3Vzc2lvbiBzbyBmYXINCg0KS3lsZSBIYW1pbHRvbiB3cm90ZToNCj4gT24gVHVlLCBEZWMg OCwgMjAwOSBhdCAxOjEzIEFNLCAgPFBhc2kuRXJvbmVuQG5va2lhLmNvbT4gd3JvdGU6DQo+PiAo d2VhcmluZyBBcmVhIERpcmVjdG9yIGhhdCkNCj4+DQo+PiAtIFdlIHJlY29tbWVuZCB0aGF0IFRM UyBsaWJyYXJpZXMgU0hPVUxEIHByb3ZpZGUgaWRlbnRpdHkgbWF0Y2hpbmcNCj4+ICh3aXRoIG1l bWNtcCwgYWJvcnQgaGFuZHNoYWtlIGlmIGNoYW5nZWQpIGZ1bmN0aW9uYWxpdHkgdG8NCj4+IGFw cGxpY2F0aW9ucywgYW5kIFNIT1VMRCBhbGxvdyBhcHBsaWNhdGlvbnMgdG8gZW5hYmxlL2Rpc2Fi bGUgdGhpcw0KPj4gZnVuY3Rpb25hbGl0eS4NCj4gDQo+IE5vLCBpZGVudGl0eSBtYXRjaGluZyBT SE9VTEQgYmUgZG9uZSBpbiBhY2NvcmRhbmNlIHdpdGggUEtJWC4NCg0KU3Ryb25nbHkgZGlzYWdy ZWUuIElmIGltcGxlbWVudGF0aW9ucyB0cnkgdG8gZG8gaWRlbnRpdHkgbWF0Y2hpbmcgdGhhdA0K aXMgYW55IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBtZW1jbXAgdGhlbiB0aGV5ICp3aWxsKiBnZXQg aXQgd3Jvbmc7IHNlZQ0KPGh0dHA6Ly93d3cuaW9hY3RpdmUuY29tL3BkZnMvUEtJTGF5ZXJDYWtl LnBkZj4gZm9yIGV2aWRlbmNlLg0KDQotLSANCkRhdmlkLVNhcmFoIEhvcHdvb2QgIOKapSAgaHR0 cDovL2Rhdmlkc2FyYWgubGl2ZWpvdXJuYWwuY29tDQoNCg== From uri@ll.mit.edu Thu Dec 17 22:08: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 4991E3A6A33 for ; Thu, 17 Dec 2009 22:08:47 -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 CrgSmQSnvE0k for ; Thu, 17 Dec 2009 22:08:47 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id DC5AD3A68DA for ; Thu, 17 Dec 2009 22:08:46 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBI68ViL025511; Fri, 18 Dec 2009 01:08:31 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAABna4vW; Fri Dec 18 01:05:59 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Fri, 18 Dec 2009 01:05:59 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'david-sarah@jacaranda.org'" , "'tls@ietf.org'" Date: Fri, 18 Dec 2009 01:05:58 -0500 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp/pcHRqt5rlWUUT9yFZqadejy2HQAAmlV2 Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854006@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 06:08:47 -0000 TXkgc3Ryb25nIGNvbnZpY3Rpb24gaXMgdGhhdCB0aGUgZmFjdCBvZiBub24temVybyBwcm9iYWJp bGl0eSB0byBnZXQgIChlLmcuKSBQS0lYIGlkZW50aXR5IG1hdGNoaW5nIHdyb25nIC0gZG9lcyBO T1QgaW52YWxpZGF0ZSB0aGUgbmVlZCBmb3Igc29tZXRoaW5nIG1vcmUgcG93ZXJmdWwgYW5kIHVz YWJsZSB0aGFuIG1lbWNtcC4gSSdtIG5vdCBjb252aW5jZWQgdGhhdCBNRDUgY29sbGlzaW9uIGV4 cGxvaXRhdGlvbiBqdXN0aWZpZXMgcmVzdHJpY3Rpb24gb2YgbWF0Y2hpbmcgdG8gbWVtY21wLg0K DQpBZ2FpbiwgbXkgc3Ryb25nIGNvbnZpY3Rpb24uDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3Jn Pg0KVG86IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYub3JnPg0KU2VudDogRnJpIERlYyAxOCAwMDo0 NzoyOCAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBTdW1tYXJpemluZyBpZGVudGl0eSBjaGFuZ2Ug ZGlzY3Vzc2lvbiBzbyBmYXINCg0KS3lsZSBIYW1pbHRvbiB3cm90ZToNCj4gT24gVHVlLCBEZWMg OCwgMjAwOSBhdCAxOjEzIEFNLCAgPFBhc2kuRXJvbmVuQG5va2lhLmNvbT4gd3JvdGU6DQo+PiAo d2VhcmluZyBBcmVhIERpcmVjdG9yIGhhdCkNCj4+DQo+PiAtIFdlIHJlY29tbWVuZCB0aGF0IFRM UyBsaWJyYXJpZXMgU0hPVUxEIHByb3ZpZGUgaWRlbnRpdHkgbWF0Y2hpbmcNCj4+ICh3aXRoIG1l bWNtcCwgYWJvcnQgaGFuZHNoYWtlIGlmIGNoYW5nZWQpIGZ1bmN0aW9uYWxpdHkgdG8NCj4+IGFw cGxpY2F0aW9ucywgYW5kIFNIT1VMRCBhbGxvdyBhcHBsaWNhdGlvbnMgdG8gZW5hYmxlL2Rpc2Fi bGUgdGhpcw0KPj4gZnVuY3Rpb25hbGl0eS4NCj4gDQo+IE5vLCBpZGVudGl0eSBtYXRjaGluZyBT SE9VTEQgYmUgZG9uZSBpbiBhY2NvcmRhbmNlIHdpdGggUEtJWC4NCg0KU3Ryb25nbHkgZGlzYWdy ZWUuIElmIGltcGxlbWVudGF0aW9ucyB0cnkgdG8gZG8gaWRlbnRpdHkgbWF0Y2hpbmcgdGhhdA0K aXMgYW55IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBtZW1jbXAgdGhlbiB0aGV5ICp3aWxsKiBnZXQg aXQgd3Jvbmc7IHNlZQ0KPGh0dHA6Ly93d3cuaW9hY3RpdmUuY29tL3BkZnMvUEtJTGF5ZXJDYWtl LnBkZj4gZm9yIGV2aWRlbmNlLg0KDQotLSANCkRhdmlkLVNhcmFoIEhvcHdvb2QgIOKapSAgaHR0 cDovL2Rhdmlkc2FyYWgubGl2ZWpvdXJuYWwuY29tDQoNCg== From marsh@extendedsubset.com Thu Dec 17 22: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 046423A6A48 for ; Thu, 17 Dec 2009 22:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKlDqnOAfAMV for ; Thu, 17 Dec 2009 22:44:46 -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 AE8AF3A6A45 for ; Thu, 17 Dec 2009 22:44: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 1NLWZi-000FrY-QF; Fri, 18 Dec 2009 06:44:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E40D26678; Fri, 18 Dec 2009 06:44: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: U2FsdGVkX18XSwH93tXbqkSbk5bmmCxunHjKPYXZPvQ= Message-ID: <4B2B24CD.30802@extendedsubset.com> Date: Fri, 18 Dec 2009 00:44:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Blumenthal, Uri - 0662 - MITLL" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854006@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854006@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 Cc: "'tls@ietf.org'" Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 06:44:47 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > My strong conviction is that the fact of non-zero probability to get > (e.g.) PKIX identity matching wrong - does NOT invalidate the need > for something more powerful and usable than memcmp. I don't believe many participants in this discussion are thinking that memcmp() is sufficient for general identity comparison, only that it works a useful percentage of the time to suggest it would be useful for TLS implementations to provide as an option to application code. > I'm not convinced > that MD5 collision exploitation justifies restriction of matching to > memcmp. I missed the email where MD5 collisions were raised. Mainly memcmp has the advantage of simplicity in definition. If a TLS implementer wanted to provide an option to compare with hashes they should just document that it works that way. - Marsh From ravi@findravi.com Thu Dec 17 22: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 9B60A3A6A4A for ; Thu, 17 Dec 2009 22:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=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 uOYw9G-Np8ss for ; Thu, 17 Dec 2009 22:50:23 -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 A377B3A6A59 for ; Thu, 17 Dec 2009 22:50:17 -0800 (PST) Received: by pzk6 with SMTP id 6so2029128pzk.29 for ; Thu, 17 Dec 2009 22:49:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.119.6 with SMTP id r6mr2397613wac.45.1261118998140; Thu, 17 Dec 2009 22:49:58 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2009 22:49:58 -0800 Message-ID: <3561bdcc0912172249i678bdbf5p89f1c3b3e8fd635@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016369208c4e75836047afb25d1 Subject: Re: [TLS] TLS Digest, Vol 65, Issue 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: Fri, 18 Dec 2009 06:50:25 -0000 --0016369208c4e75836047afb25d1 Content-Type: text/plain; charset=UTF-8 > I do agree with you there. Unless the saved session mechanism also > triggers the functionality and checks that a full handshake would, but > I think that's too much to hope for. > > -Kyle H I know everyone on this thread knows otherwise, but the way the terms get used, can easily result in confusion between "full handshake", "abbreviated handshake" and "renegotiated full handshake". The attack only applies of course to last category, and NOT to the abbreviated handshake. To be pedantic, in the "full" handshake the two sides (or at least the Server) prove identity to each other using their private keys and certificates chaining to mutually trusted roots, and exchange the "master_secret" which is really the "session key". This "master_secret" can be used by the "abbreviated handshake" to create many (including parallel) subsequent sessions with each party proving identity here by proving possession of the session key (the "master secret"). During the abbreviated handshake one simply CANNOT do all the checks in the full handshake, not because the developer chose not to do it, but because there is no question of public key credentials...the abbreviated handshake is relying purely on the shared secret (via the server.verify and client.verify). Sorry if this is so obvious to those on this thread, but a lot about SSL is *not* obvious to the world at general, and unfortunately a number of people are convinced that the attack discovered a flaw in session resumption or opening parallel sessions using the abbreviated handshake. If it did, I missed it perhaps. If not, perhaps language in text clarifying this 'obvious' point might be useful. Thanks, Ravi -- Ravi Ganesan ravi@findravi.com www.findravi.com --0016369208c4e75836047afb25d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > I do agree with you there. =C2=A0Unless the saved session mechanism al= so
> triggers the functionality and checks that a full handshake would, but=
> I think that's too much to hope for.
>
> -Kyle H


I know everyone on this thread knows = otherwise, but the way the terms get used, can easily result in confusion b= etween "full handshake", "abbreviated handshake" and &q= uot;renegotiated full handshake".=C2=A0 The attack only applies of cou= rse to last category, and NOT to the abbreviated handshake.

To be pedantic, in the "full" handshake the two sides (or at = least the Server) prove identity to each other using their private keys and= certificates chaining to mutually trusted roots, and exchange the "ma= ster_secret" which is really the "session key". This "m= aster_secret" can be used by the "abbreviated handshake" to = create many (including parallel) subsequent sessions with each party provin= g identity here by proving possession of the session key (the "master = secret"). During the abbreviated handshake one simply CANNOT do all th= e checks in the full handshake, not because the developer chose not to do i= t, but because there is no question of public key credentials...the abbrevi= ated handshake is relying purely on the shared secret (via the server.verif= y and client.verify).

Sorry if this is so obvious to those on this thread, but a lot about SS= L is *not* obvious to the world at general, and unfortunately a number of p= eople are convinced that the attack discovered a flaw in session resumption= or opening parallel sessions using the abbreviated handshake. If it did, I= missed it perhaps.=C2=A0 If not, perhaps language in text clarifying this = 'obvious' point might be useful.

Thanks,

Ravi
--
Ravi Ganesan
ravi@findravi.com
w= ww.findravi.com
--0016369208c4e75836047afb25d1-- From marsh@extendedsubset.com Thu Dec 17 23:25: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 BE4D53A6A1C for ; Thu, 17 Dec 2009 23:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pb8dGrogSvh for ; Thu, 17 Dec 2009 23:25: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 E35433A67E1 for ; Thu, 17 Dec 2009 23:25:31 -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 1NLXDB-000CwJ-05; Fri, 18 Dec 2009 07:25:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BDCD26678; Fri, 18 Dec 2009 07:25: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: U2FsdGVkX19z1gTItDS22lalnjUMy6auFHaZh3aGuYs= Message-ID: <4B2B2E5A.90805@extendedsubset.com> Date: Fri, 18 Dec 2009 01:25:14 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ravi Ganesan References: <3561bdcc0912172249i678bdbf5p89f1c3b3e8fd635@mail.gmail.com> In-Reply-To: <3561bdcc0912172249i678bdbf5p89f1c3b3e8fd635@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] TLS Digest, Vol 65, Issue 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: Fri, 18 Dec 2009 07:25:32 -0000 Ravi Ganesan wrote: > > I know everyone on this thread knows otherwise, but the way the terms > get used, can easily result in confusion between "full handshake", > "abbreviated handshake" and "renegotiated full handshake". It took me a long time to stop getting mixed up between "renegotiation" and "resumption". There was some discussion about this, but it turns out they are completely orthogonal. > The attack > only applies of course to last category, and NOT to the abbreviated > handshake. No, it applies equally to session resumption "abbreviated" handshakes. They can also be conducted during a renegotiation. OpenSSL even defines an option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. I'm sure there's a story behind that one. > [...] > > Sorry if this is so obvious to those on this thread, but a lot about SSL > is *not* obvious to the world at general, and unfortunately a number of > people are convinced that the attack discovered a flaw in session > resumption or opening parallel sessions using the abbreviated handshake. > If it did, I missed it perhaps. If not, perhaps language in text > clarifying this 'obvious' point might be useful. draft-ietf-tls-renegotiation-02 contains the text: > The above rules apply even when TLS session resumption is used. and > TLS clients which support this specification MUST generate either the > "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST > SCSV with every ClientHello, including ClientHellos where session > resumption is being offered. The RI extension should fix renegotiation regardless of whether a new session is being established or a previous session is being resumed. - Marsh From jsalowey@cisco.com Thu Dec 17 23:27: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 E40963A67E1 for ; Thu, 17 Dec 2009 23:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 a++2ibIZmR5j for ; Thu, 17 Dec 2009 23:27:34 -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 0A8873A683F for ; Thu, 17 Dec 2009 23:27: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: ApoEABq9KkurR7Hu/2dsb2JhbAC9a5cmgi4GgXkE X-IronPort-AV: E=Sophos;i="4.47,417,1257120000"; d="scan'208";a="281210108" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Dec 2009 07:27:19 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBI7RJvh019987; Fri, 18 Dec 2009 07:27:19 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, 17 Dec 2009 23:27:19 -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, 17 Dec 2009 23:27:16 -0800 Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: Acp/YSMJ21qxpPadSkKKYtCdVu/oAQAACc+AABOtZVA= References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com><6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> From: "Joseph Salowey (jsalowey)" To: , X-OriginalArrivalTime: 18 Dec 2009 07:27:19.0629 (UTC) FILETIME=[884FDFD0:01CA7FB3] Cc: tls@ietf.org Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 07:27:37 -0000 I share the opinion that identity checking belongs in the application, performed according to whatever mechanism is appropriate. We should not be mandating any particular PKIX processing in the TLS specs.=20 I also think if an application is not prepared to be aware of renegotiation and handle any identity change associated with it then renegotiation should be disabled. This implies that renegotiation should be disabled by default and specifically enabled by an application. So I would say "TLS implementations SHOULD disable renegotiation by default and offer the applications the option to enable renegotiation. When an application enables renegotiation it must handle identity processing for each handshake." I don't think binary certificate comparison is necessarily the most valid comparison for applications to use. I'm not convinced it will make life simpler for applications. =20 Joe > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Pasi.Eronen@nokia.com > Sent: Thursday, December 17, 2009 2:06 PM > To: aerowolf@gmail.com > Cc: tls@ietf.org > Subject: Re: [TLS] Summarizing identity change discussion so far >=20 > Kyle Hamilton wrote: >=20 > > No, identity matching SHOULD be done in accordance with=20 > PKIX. memcmp=20 > > is not at all sufficient. > >=20 > > However, I would support the following: > >=20 > > - TLS libraries SHOULD provide identity matching services=20 > between and=20 > > throughout renegotiation handshakes. Libraries SHOULD=20 > implement this=20 > > in accordance with PKIX [PKIX], but MAY do so with a direct memory=20 > > comparison. Implementors are cautioned that this latter=20 > approach does=20 > > not provide for changing the cipher parameters -- such as a=20 > > renegotiation with an EC or DH certificate after=20 > identification with=20 > > an RSA certificate. If the identity matching service fails=20 > to match=20 > > the identity, implementations MUST abort the handshake with a fatal=20 > > bad_certificate alert. >=20 > Well, the text I proposed just said "different certificate",=20 > not "memcmp". I know that's a bit vague, but "in accordance=20 > with PKIX [PKIX]" is not very precise either, and would need=20 > a more specific reference to where exactly the details are=20 > (for example, it can't mean comparing the Subject field,=20 > since PKIX allows leaving it empty). >=20 > And the certificate might have extensions (certificate=20 > policies, subject directory attributes, extended key usage,=20 > etc.) where changes between API calls could surprise the application. >=20 > Here's another shot at that paragraph (also including=20 > suggestions from Marsh's email): >=20 > TLS implementations SHOULD offer the applications the option to > disable renegotiation completely. >=20 > To make life simpler for applications that do not expect the peer's > certificate to change once it's been authenticated, TLS > implementations may also wish to offer the applications the option > abort the renegotiation if the peer tries to authenticate with a > different certificate and/or different server name (in the > server_name extension) than was used earlier. However, enabling > this option by default for all applications could break existing > applications that depend on using renegotiation to change from one > certificate to another. (For example, long-lived TLS connections > could change to a renewed certificate; or renegotiation could > select a different cipher suite that requires using a different > certificate.) >=20 > Best regards, > Pasi > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From ravi@findravi.com Thu Dec 17 23:55: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 CB5033A683F for ; Thu, 17 Dec 2009 23:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 IcYhdMm404ZS for ; Thu, 17 Dec 2009 23:55:43 -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 7F9033A6828 for ; Thu, 17 Dec 2009 23:55:42 -0800 (PST) Received: by pzk6 with SMTP id 6so2056149pzk.29 for ; Thu, 17 Dec 2009 23:55:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.80.6 with SMTP id h6mr2405320wal.108.1261122924604; Thu, 17 Dec 2009 23:55:24 -0800 (PST) In-Reply-To: <4B2B2E5A.90805@extendedsubset.com> References: <3561bdcc0912172249i678bdbf5p89f1c3b3e8fd635@mail.gmail.com> <4B2B2E5A.90805@extendedsubset.com> Date: Thu, 17 Dec 2009 23:55:24 -0800 Message-ID: <3561bdcc0912172355j6ff1ec8bp69a22627823af092@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e64dc8fef06e2b047afc0f53 Subject: Re: [TLS] TLS Digest, Vol 65, Issue 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: Fri, 18 Dec 2009 07:55:43 -0000 --0016e64dc8fef06e2b047afc0f53 Content-Type: text/plain; charset=UTF-8 > > The attack > > only applies of course to last category, and NOT to the abbreviated > > handshake. > > No, it applies equally to session resumption "abbreviated" handshakes. > > They can also be conducted during a renegotiation. OpenSSL even defines > an option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. I'm sure > there's a story behind that one. > > Marsh, I re-read the relevant links and it did not jump out on me. Am sure I am missing something but can you elaborate on how this happens? i.e. the genuine Client and geniune Server have agreed on a master secret using their respective certs, and are trying to establish a new session using the abbreviated handshake, using the session_key (the master_secret, which hopefully in TLS 1.x will be renamed the session_key!). How does MITM intervene? Thx. -- Ravi Ganesan ravi@findravi.com www.findravi.com --0016e64dc8fef06e2b047afc0f53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> The attack
> only applies of course to last category, and NOT to the abbreviated > handshake.

No, it applies equally to session resumption "abbreviated" = handshakes.

They can also be conducted during a renegotiation. OpenSSL even defines
an option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. I'm sure
there's a story behind that one.


Marsh, I re-read the relevant links and it did no= t jump out on me. Am sure I am missing something but can you elaborate on h= ow this happens? i.e. the genuine Client and geniune Server have agreed on = a master secret using their respective certs, and are trying to establish a= new session using the abbreviated handshake, using the session_key (the ma= ster_secret, which hopefully in TLS 1.x will be renamed the session_key!). = How does MITM intervene? Thx.
=C2=A0
--
Ravi Ganesan
ravi@findravi.com
www.findrav= i.com
--0016e64dc8fef06e2b047afc0f53-- From rdugal@certicom.com Fri Dec 18 04:11: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 EAC333A6A18 for ; Fri, 18 Dec 2009 04:11:31 -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=[AWL=0.000, 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 vyr3KElmXe6i for ; Fri, 18 Dec 2009 04:11:30 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 39F9B3A67E3 for ; Fri, 18 Dec 2009 04:11:29 -0800 (PST) X-AuditID: 0a666446-b7ba5ae000003caa-6e-4b2b716114d2 Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 66.7E.15530.1617B2B4; Fri, 18 Dec 2009 07:11:14 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 07:11:13 -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, 18 Dec 2009 07:10:29 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402EEEAF1@XCH57YKF.rim.net> In-Reply-To: <4B2A73C7.7030505@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Updated draft Thread-Index: Acp/Q9x5TdGgr/rmRe+ruOj96MCGpwAlVOoQ References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@pobox.com> From: "Robert Dugal" To: "TLS Mailing List" X-OriginalArrivalTime: 18 Dec 2009 12:11:13.0558 (UTC) FILETIME=[31532B60:01CA7FDB] X-Brightmail-Tracker: AAAABAAAAZESGurlEhrsOBIa7Dk= Subject: Re: [TLS] Updated 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, 18 Dec 2009 12:11:32 -0000 I would also like to see that change in the draft. To increase interoperability with existing servers I would like the option t= o send SCSV in the initial ClientHello and only send the TLS extension in renegotiation= handshakes. This will make it easier for applications as they won't have to make a decis= ion as to whether the server is TLS extension intolerant. -- 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: Thursday, December 17, 2009 1:09 PM To: TLS Mailing List Subject: Re: [TLS] Updated draft s/signalling/signaling/g In section 4 it says: Because the SCSV is equivalent to an empty "renegotiation_info" extension, any ClientHello used for secure renegotiation MUST include the "renegotiation_info" extension and not the SCSV. I would rather see the text say that "an RI extension takes precedence over the SCSV" than to say that you must not send SCSV when you send RI. It is easier for a client to simply include SCSV in every ClientHello. It is also trivial for a server to handle this, as I pointed out in my last message. Mike Eric Rescorla wrote: > I've just submitted a new draft that is intended to enact most of > Pasi's message as well as the noncontroversial editorial comments > people have raised. Here is what I know still needs work: > > - The final resolution to what's sent in the legacy renegotiation > case (see Pasi's message and the text I sent earlier). > - New text for the identity section in Security considerations. > (Pending closure on the list). > - Make a pass through for clarity for implementors. > (Also, I have some text here that Pasi contributed that I > need to work in). > > If you think you made a comment which is noncontroversial > that didn't make it in and/or I screwed up incorporating your > comment, please let me know and I'll try to fix. > > For some reason, the submission tool is forcing manual > submission. In the interim you can find it at: > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate= .txt > > Thanks, > -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 stephen.farrell@cs.tcd.ie Fri Dec 18 04:20: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 7A9393A688C for ; Fri, 18 Dec 2009 04:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 Md-sVuKPecoT for ; Fri, 18 Dec 2009 04:20:14 -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 193A13A6A75 for ; Fri, 18 Dec 2009 04:20:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id DF3C83600A5; Fri, 18 Dec 2009 12:19:57 +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 nNkc9CzWHoV7; Fri, 18 Dec 2009 12:19:56 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id BE407360092; Fri, 18 Dec 2009 12:19:56 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 988D77C309; Fri, 18 Dec 2009 12:19:56 +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 KDvqezkt67sJ; Fri, 18 Dec 2009 12:19:55 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id E6BF57C323; Fri, 18 Dec 2009 12:19:55 +0000 (GMT) Message-ID: <4B2B7371.7060101@cs.tcd.ie> Date: Fri, 18 Dec 2009 12:20:01 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BBB@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F77BBB@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] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 12:20:15 -0000 Text like this is much better and would remove the concern I expressed before (that this spec is not the place to do more than just fix the renegotiation bug). Adding positive examples (games/XMPP) as Martin suggested would be a fine addition to this. Delving into details of PKIX or other identity matching would not be fine IMO. S. Pasi.Eronen@nokia.com wrote: > Here's proposed text for the Security Considerations section about the > identity changes. The discussion on the list seemed to favor keeping > the normative parts quite mild, so much of this is worded as advice > for people to consider (or ignore, if they so choose), not as strict > requirements: > > While this extension mitigates the man-in-the-middle attack > described in the overview, it does not resolve all possible > problems an application may face if it is unaware of renegotiation. > In particular, either the client or the server can during > renegotiation present a different certificate than was used > earlier, and this may become as a surprise to application > developers (who might have expected, for example, that a > "getPeerCertificates()" API call returns the same value if called > twice), and might be handled in an insecure way. > > TLS implementers are encouraged to clearly document how > renegotiation interacts with the APIs offered to applications (for > example, which API calls might return different values on different > calls, or which callbacks might get called multiple times). > > To make life simpler for applications that do not expect the peer's > certificate to change once it's been authentication, TLS > implementations MAY offer the applications the option abort the > renegotiation if the peer tries to authenticate with a different > certificate and/or different server name (in the server_name > extension) than was used earlier. However, enabling this option by > default for all applications could break existing applications that > depend on using renegotiation to present multiple certificates. > TLS implementations SHOULD also offer the applications the option > to disable renegotiation completely. > > Finally, designers of applications that depend on renegotiation are > reminded that many TLS APIs represent application data as a simple > octet stream; applications may not be able to determine exactly > which application data octets were received before, during, or > after renegotiation. Especially if the peer presents a different > certificate during renegotiation, care is needed when specifying > how the application should handle the data. > > Comments (and especially concrete proposals for improving the text) > are welcome. > > Best regards, > Pasi > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Eronen Pasi (Nokia-NRC/Helsinki) >> Sent: 08 December, 2009 11:13 >> To: tls@ietf.org >> Subject: [TLS] Summarizing identity change discussion so far >> >> (wearing Area Director hat) >> >> Although the IETF Last Call is still underway, here's a short attempt >> to summarize the discussion regarding identity changes (Section 7) so >> far: >> >> - We seem to agree that changing the certificate/identity >> during secure renegotiation (so there's no man-in-the-middle, just two >> parties) could confuse some applications. James Manger's email >> provides >> IMHO a good example of what that confusion could be (in this particular >> example, the confusion has security implications, too): >> >> http://www.ietf.org/mail-archive/web/tls/current/msg05122.html >> >> - We mostly seem to agree that some applications could not just handle >> certificate/identity changes correctly, but would actually benefit >> from them. >> >> - We seem to agree that it would be a reasonable idea for the TLS >> library to offer the applications an option where the TLS library >> checks that the certificate doesn't change during renegotiation. >> This is an *option* -- an application could decide not to use it, >> and e.g. do more complex comparisons. >> >> - We have much less support for requiring that every TLS library >> MUST implement this functionality and/or MUST enable it by default >> (whatever "by default" means in your API), at least in this draft. >> >> Unless I'm badly misreading the situation, or it significantly changes >> during the rest of the IETF Last Call, my proposal here would be as >> follows: >> >> - We do NOT require (with "MUST") any changes to TLS libraries in this >> regard. >> >> - We describe the situation a bit more clearly than the current text >> does (it seems many people found the current text somewhat unclear). >> >> - We recommend that TLS libraries SHOULD provide identity matching >> (with memcmp, abort handshake if changed) functionality to >> applications, and SHOULD allow applications to enable/disable this >> functionality. >> >> - We include a sentence or two describing the pros and cons of >> enabling/not enabling this feature by default, but don't require or >> recommend any particular default value. >> >> - The text probably needs to note that if the applications wants to >> deal with identity changes, it may need to consider the "which >> application_data byte(s) correspond to which identity" question (or it >> may not -- the answer may depend a lot on the application protocol). >> >> Does this sound like a reasonable approach? >> >> Best regards, >> Pasi >> _______________________________________________ >> 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 Fri Dec 18 06:42: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 0CFDC3A68F1 for ; Fri, 18 Dec 2009 06:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08DVyhN7MSMv for ; Fri, 18 Dec 2009 06:42: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 41CB93A68A5 for ; Fri, 18 Dec 2009 06:42: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 1NLe1y-000FrR-6D; Fri, 18 Dec 2009 14:42:10 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 121B36678; Fri, 18 Dec 2009 14:42:09 +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+ae6gJFHT5RsbhwMx+p+z9VxpDC0RkeCA= Message-ID: <4B2B94C0.7080302@extendedsubset.com> Date: Fri, 18 Dec 2009 08:42:08 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Dugal References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@pobox.com> <7E1DF37F1F42AB4E877E492C308E6AC402EEEAF1@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402EEEAF1@XCH57YKF.rim.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: TLS Mailing List Subject: Re: [TLS] Updated 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, 18 Dec 2009 14:42:26 -0000 Robert Dugal wrote: > I would also like to see that change in the draft. > > To increase interoperability with existing servers I would like the option to send SCSV > in the initial ClientHello and only send the TLS extension in renegotiation handshakes. Isn't that how it's worded now? > This will make it easier for applications as they won't have to make a decision as to > whether the server is TLS extension intolerant. If I were writing a new app that wasn't intended to be the most widely used web browser in the world, I wouldn't bother with the SCSV at all. Otherwise, just send it every time instead of an empty RI extension. - Marsh From rdugal@certicom.com Fri Dec 18 07:09: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 1209A3A69E4 for ; Fri, 18 Dec 2009 07:09:54 -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=[AWL=0.000, 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 pVYOeaqsS2iH for ; Fri, 18 Dec 2009 07:09:53 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 10DFE3A6892 for ; Fri, 18 Dec 2009 07:09:52 -0800 (PST) X-AuditID: 0a666446-b7ba5ae000003caa-db-4b2b9b311396 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 9B.B8.15530.13B9B2B4; Fri, 18 Dec 2009 10:09:37 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 10:09:37 -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, 18 Dec 2009 10:08:40 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402EEEC63@XCH57YKF.rim.net> In-Reply-To: <4B2B94C0.7080302@extendedsubset.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Updated draft Thread-Index: Acp/8EiPYmlbD/SsTFOnZJb6oXwtvQAAnSUQ References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@pobox.com> <7E1DF37F1F42AB4E877E492C308E6AC402EEEAF1@XCH57YKF.rim.net> <4B2B94C0.7080302@extendedsubset.com> From: "Robert Dugal" To: "TLS Mailing List" X-OriginalArrivalTime: 18 Dec 2009 15:09:37.0262 (UTC) FILETIME=[1D3AC8E0:01CA7FF4] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [TLS] Updated 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, 18 Dec 2009 15:09:54 -0000 Oops, you're right. I misstated what I'd like the draft to allow. What I'd like is the option to always send the SCSV in the ClientHello and o= n renegotiation requests send the SCSV + RI extension in the ClientHello. -- 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: Marsh Ray [mailto:marsh@extendedsubset.com] Sent: Friday, December 18, 2009 9:42 AM To: Robert Dugal Cc: TLS Mailing List Subject: Re: [TLS] Updated draft Robert Dugal wrote: > I would also like to see that change in the draft. > > To increase interoperability with existing servers I would like the option= to send SCSV > in the initial ClientHello and only send the TLS extension in renegotiatio= n handshakes. Isn't that how it's worded now? > This will make it easier for applications as they won't have to make a dec= ision as to > whether the server is TLS extension intolerant. If I were writing a new app that wasn't intended to be the most widely used web browser in the world, I wouldn't bother with the SCSV at all. Otherwise, just send it every time instead of an empty RI extension. - Marsh ---------------------------------------------------------------------=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 ekr@networkresonance.com Fri Dec 18 07:31: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 7F8EA3A6A7C for ; Fri, 18 Dec 2009 07:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 XoQGuuU1lDUJ for ; Fri, 18 Dec 2009 07:31: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 B7D673A690D for ; Fri, 18 Dec 2009 07:31:37 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 6E1F56C872F; Fri, 18 Dec 2009 07:31:53 -0800 (PST) Date: Fri, 18 Dec 2009 07:31:53 -0800 From: Eric Rescorla To: Michael D'Errico In-Reply-To: <4B2A73C7.7030505@pobox.com> References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@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: <20091218153153.6E1F56C872F@kilo.networkresonance.com> Cc: TLS Mailing List Subject: Re: [TLS] Updated 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, 18 Dec 2009 15:31:49 -0000 At Thu, 17 Dec 2009 10:09:11 -0800, Michael D'Errico wrote: > > s/signalling/signaling/g > > In section 4 it says: > > Because the SCSV is equivalent to an empty "renegotiation_info" > extension, any ClientHello used for secure renegotiation MUST include > the "renegotiation_info" extension and not the SCSV. > > I would rather see the text say that "an RI extension takes precedence > over the SCSV" than to say that you must not send SCSV when you send RI. > It is easier for a client to simply include SCSV in every ClientHello. > It is also trivial for a server to handle this, as I pointed out in my > last message. This implements the following point from Pasi's message. - There was some discussion on whether to add the magic cipher suite to patched renegotiation ClientHellos (in addition to the extension), too. I believe rough consensus is not to do this. It's of course possible I misunderstood. -Ekr From mrex@sap.com Fri Dec 18 07: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 E15053A67AE for ; Fri, 18 Dec 2009 07:49:05 -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 blRoIT97PpvC for ; Fri, 18 Dec 2009 07:49:05 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D70463A672E for ; Fri, 18 Dec 2009 07:49:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIFmm4d009495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 16:48:48 +0100 (MET) From: Martin Rex Message-Id: <200912181548.nBIFmlCk021658@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Fri, 18 Dec 2009 16:48:47 +0100 (MET) In-Reply-To: <20091218153153.6E1F56C872F@kilo.networkresonance.com> from "Eric Rescorla" at Dec 18, 9 07:31:53 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] Updated 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: Fri, 18 Dec 2009 15:49:06 -0000 Eric Rescorla wrote: > > At Thu, 17 Dec 2009 10:09:11 -0800, > Michael D'Errico wrote: > > > > s/signalling/signaling/g > > > > In section 4 it says: > > > > Because the SCSV is equivalent to an empty "renegotiation_info" > > extension, any ClientHello used for secure renegotiation MUST include > > the "renegotiation_info" extension and not the SCSV. > > > > I would rather see the text say that "an RI extension takes precedence > > over the SCSV" than to say that you must not send SCSV when you send RI. > > It is easier for a client to simply include SCSV in every ClientHello. > > It is also trivial for a server to handle this, as I pointed out in my > > last message. > > This implements the following point from Pasi's message. > > - There was some discussion on whether to add the magic cipher suite > to patched renegotiation ClientHellos (in addition to the extension), > too. I believe rough consensus is not to do this. > > It's of course possible I misunderstood. I believe that Pasi mainly tried to summarize what he found in the discussion, and that discussion was huge and pretty fragmented. A lot of things were discussed with a number of different semantics. Personllay, I find it difficult to assess consensus on some topics of the severely fragmented discussions. I would like to read Pasi's summary as a suggestion to the Working Group how to resolve the discussed issues, and it is up to the working group to decide whether the individual items are actually the outcome with the most support. Certainly we do not want to re-open each and every issue again. What Mike and Robert are writing looks like implementers experience to me, they tried to add the current changes in the spec and are requesting changes that would make their implementation simpler. I would appreciate if the spec would be more careful about MUST NOTs, because we exhibit a tendency to be overly strict in our specs. (I had a servere MUST NOT infection in my first draft, and removing all except those that are actually required made my document more comprehensible). -Martin From marsh@extendedsubset.com Fri Dec 18 08:37: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 7C2DC3A6991 for ; Fri, 18 Dec 2009 08:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNUbTQwuox2v for ; Fri, 18 Dec 2009 08:37:19 -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 7398E3A68AD for ; Fri, 18 Dec 2009 08:37:19 -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 1NLfpA-0003LL-Cg; Fri, 18 Dec 2009 16:37:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8E2D86678; Fri, 18 Dec 2009 16:37: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: U2FsdGVkX1/HX9xh+JSxslD4wP/x7LNWQSyQz2uAqVI= Message-ID: <4B2BAFAC.9020501@extendedsubset.com> Date: Fri, 18 Dec 2009 10:37:00 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Dugal References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@pobox.com> <7E1DF37F1F42AB4E877E492C308E6AC402EEEAF1@XCH57YKF.rim.net> <4B2B94C0.7080302@extendedsubset.com> <7E1DF37F1F42AB4E877E492C308E6AC402EEEC63@XCH57YKF.rim.net> In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402EEEC63@XCH57YKF.rim.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: TLS Mailing List Subject: Re: [TLS] Updated 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, 18 Dec 2009 16:37:20 -0000 Robert Dugal wrote: > Oops, you're right. I misstated what I'd like the draft to allow. > What I'd like is the option to always send the SCSV in the > ClientHello and on renegotiation requests send the SCSV + RI > extension in the ClientHello. That certainly sounds like a reasonably minor change to make...but it isn't. I don't recall seeing anyone propose wording changes that would allow such behavior, except in the context of the other proposals which are fundamentally different in that they modify the inputs to the PRF. It's possible that some concrete wording was suggested and is in one of the 1340 emails in my TLS folder. Currently, the SCSV achieves its primary objective with a very simple definition. It has "exactly the same semantics as an empty 'renegotiation_info' extension". IMHO, proponents of other semantics for SCSV should be able to produce an equally straightforward description of what they are, or show something truly magical to justify complicating the description. Saving an 'if' statement somewhere, partially fixing a multiply-broken scenario, or avoiding extensions handling in some non-general case don't sound like they justify the extra complexity. Personally, I'd prefer that we don't propose (and re-propose) design features at this point. We have to ship a fix for this open security vulnerability, and I think the current design is squarely in the "good enough" department. I.e. it fixes the problem and doesn't make anything else significantly worse. If anyone sees a security flaw or attack against a correct implementation of draft-ietf-tls-renegotiation-02, please please speak up. - Marsh From mrex@sap.com Fri Dec 18 09: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 6C0503A67F1 for ; Fri, 18 Dec 2009 09:14:12 -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.248, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=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 RmvZXTaFveHF for ; Fri, 18 Dec 2009 09:14: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 C628C3A68E8 for ; Fri, 18 Dec 2009 09:14:10 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIHDoQI025064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 18:13:51 +0100 (MET) From: Martin Rex Message-Id: <200912181713.nBIHDo9C026697@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 18 Dec 2009 18:13:50 +0100 (MET) In-Reply-To: <4B2BAFAC.9020501@extendedsubset.com> from "Marsh Ray" at Dec 18, 9 10:37:00 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: rdugal@certicom.com, tls@ietf.org Subject: Re: [TLS] Updated 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: Fri, 18 Dec 2009 17:14:12 -0000 Marsh Ray wrote: > > Robert Dugal wrote: > > Oops, you're right. I misstated what I'd like the draft to allow. > > What I'd like is the option to always send the SCSV in the > > ClientHello and on renegotiation requests send the SCSV + RI > > extension in the ClientHello. > > That certainly sounds like a reasonably minor change to make. Full agreement. > > I don't recall seeing anyone propose wording changes that would allow > such behavior, I can help you solve that problem: http://www.imc.org/ietf-tls/mail-archive/msg11082.html http://www.ietf.org/mail-archive/web/tls/current/msg05305.html I know how you feel, I'm having analogus problem with my memory, I can not remember anyone making a technical argument for this particular MUST NOT here. I already asked Pasi: http://www.ietf.org/mail-archive/web/tls/current/msg05401.html but he doesn't seem to recall anything either. > > Currently, the SCSV achieves its primary objective with a very simple > definition. It has "exactly the same semantics as an empty > 'renegotiation_info' extension". That seems to be a fairly simple copy&paste error, and can easily be fixed by simple wordsmithing. It is fairly common that an initially beautiful wording turns out to add unnecessary implementation complexity when the first implementors get at the code. That usually isn't a problem, since the IETF favours running code over wording in the spec. Implementors feedback is extremely valuable. > > Personally, I'd prefer that we don't propose (and re-propose) design > features at this point. We're discussing a simple implementation detail, it does not touch the design of the underlying architecture. > > If anyone sees a security flaw or attack against a correct > implementation of draft-ietf-tls-renegotiation-02, please please speak up. If anyone sees a security flaw or technical problem with dropping this MUST NOT, then please speak up. -Martin From mike-list@pobox.com Fri Dec 18 09:17: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 E679C3A69D0 for ; Fri, 18 Dec 2009 09:17:32 -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 A6Yt6UUyThIp for ; Fri, 18 Dec 2009 09:17: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 B2B363A6930 for ; Fri, 18 Dec 2009 09:17:15 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 83F1B8935C for ; Fri, 18 Dec 2009 12:17:00 -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=IWehX5Wm2pBL gmn2W85NWaoS/i4=; b=GPWW3m1qaS9axZ0261Wb88H45zkB5COGaG6blpq5bxK0 JurxFoxMbD3gEkkKRttmCr5RLmJD2TCBSURSBY66+hRMc0fGbSdYX0fmYeb8CnK2 y1zTNvdrjPDoLptIR2irEbkMXLr4FOZjVueEwYbWRflO7/gkQ4huV6qFEXFnG/4= 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=GuNn17 uMua98ZE3aFdOSSz5SU5r5sMgBtzMOqBuNi7idR96wpMxEMXz434jHzUdCCIdB2o PIZPjsLdRzMzOpm/uYcTKP+zPPMZdgE4Sahw0i0VHzD7KPSFUopLNzRLTcKc6OSQ 8IJ6a0Pb/xVhQaMyFm1yrHBxXUnLGsz8Df4N8= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7E5668935B for ; Fri, 18 Dec 2009 12:17: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 B70358935A for ; Fri, 18 Dec 2009 12:16:59 -0500 (EST) Message-ID: <4B2BB978.30504@pobox.com> Date: Fri, 18 Dec 2009 09:18:48 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Mailing List References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@pobox.com> <20091218153153.6E1F56C872F@kilo.networkresonance.com> In-Reply-To: <20091218153153.6E1F56C872F@kilo.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2734A368-EBF9-11DE-ADAE-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Updated 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, 18 Dec 2009 17:17:52 -0000 I disagree with Pasi and with the current wording in the draft. That was the reason I sent the message. I'd like to see this changed. I have implemented the spec, and see that it creates a MUST NOT that is unnecessary. The current draft suggests that if a server sees SCSV in cipher suites and then sees RI in the ClientHello.extensions, it must abort the handshake! That is not necessary at all. The RI simply overrides the SCSV if it contains any data. It is trivial for a server to handle receiving both: - if SCSV is encountered, set a flag - if RI is encountered, set the same flag and extract the data These happily coexist with no special cases, so requiring an abort is not a good idea; it just adds complexity. The problem appears to be the statement that SCSV is equivalent to an empty RI, and thus would be a conflict if there was also an RI with data. This can be fixed by saying that SCSV is to be ignored when an RI is also received. Mike Eric Rescorla wrote: > At Thu, 17 Dec 2009 10:09:11 -0800, > Michael D'Errico wrote: >> s/signalling/signaling/g >> >> In section 4 it says: >> >> Because the SCSV is equivalent to an empty "renegotiation_info" >> extension, any ClientHello used for secure renegotiation MUST include >> the "renegotiation_info" extension and not the SCSV. >> >> I would rather see the text say that "an RI extension takes precedence >> over the SCSV" than to say that you must not send SCSV when you send RI. >> It is easier for a client to simply include SCSV in every ClientHello. >> It is also trivial for a server to handle this, as I pointed out in my >> last message. > > This implements the following point from Pasi's message. > > - There was some discussion on whether to add the magic cipher suite > to patched renegotiation ClientHellos (in addition to the extension), > too. I believe rough consensus is not to do this. > > It's of course possible I misunderstood. > > -Ekr From stephen.farrell@cs.tcd.ie Fri Dec 18 09:23: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 1DA963A6890 for ; Fri, 18 Dec 2009 09:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 NVrmxdJ7NoPW for ; Fri, 18 Dec 2009 09:23:30 -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 C0CE03A6A7C for ; Fri, 18 Dec 2009 09:23:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id E3D7E3600AA; Fri, 18 Dec 2009 17:22:58 +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 3XaS7qpgYb93; Fri, 18 Dec 2009 17:22:58 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 3836F3600A4; Fri, 18 Dec 2009 17:22:58 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 1A0307C31A; Fri, 18 Dec 2009 17:22:58 +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 oHsrU0r+vGLI; Fri, 18 Dec 2009 17:22:57 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id 868FA7C309; Fri, 18 Dec 2009 17:22:57 +0000 (GMT) Message-ID: <4B2BBA78.8020702@cs.tcd.ie> Date: Fri, 18 Dec 2009 17:23:04 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912181713.nBIHDo9C026697@fs4113.wdf.sap.corp> In-Reply-To: <200912181713.nBIHDo9C026697@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rdugal@certicom.com, tls@ietf.org Subject: Re: [TLS] Updated 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, 18 Dec 2009 17:23:36 -0000 Please Martin, the level of argument here is declining badly. Martin Rex wrote: > Marsh Ray wrote: >> Robert Dugal wrote: >>> Oops, you're right. I misstated what I'd like the draft to allow. >>> What I'd like is the option to always send the SCSV in the >>> ClientHello and on renegotiation requests send the SCSV + RI >>> extension in the ClientHello. >> That certainly sounds like a reasonably minor change to make. > > Full agreement. Except Marsh didn't say that. He said: > That certainly sounds like a reasonably minor change to make...but it isn't. Which is totally different. For me, such tactics, and frequent exaggeration, badly damage whatever it is you're trying to say in the many many long posts you've sent on this topic. I think its past time to stop all that. Stephen. From mrex@sap.com Fri Dec 18 09: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 82F4F3A68C3 for ; Fri, 18 Dec 2009 09:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 ilsQFRDmkTtS for ; Fri, 18 Dec 2009 09:31:50 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 77DC13A67FE for ; Fri, 18 Dec 2009 09:31:50 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIHVYKw016037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Dec 2009 18:31:34 +0100 (MET) From: Martin Rex Message-Id: <200912181731.nBIHVYOG027690@fs4113.wdf.sap.corp> Orig-To: stephen.farrell@cs.tcd.ie (Stephen Farrell) To: tls@ietf.org Date: Fri, 18 Dec 2009 18:30:12 +0100 (MET) Cc: tls@ietf.org In-Reply-To: <4B2BBA78.8020702@cs.tcd.ie> from "Stephen Farrell" at Dec 18, 9 05:23:04 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal05 X-SAP: out Subject: Re: [TLS] Updated 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: Fri, 18 Dec 2009 17:31:51 -0000 Stephen Farrell wrote: > > Martin Rex wrote: > > Marsh Ray wrote: > >> Robert Dugal wrote: > >>> Oops, you're right. I misstated what I'd like the draft to allow. > >>> What I'd like is the option to always send the SCSV in the > >>> ClientHello and on renegotiation requests send the SCSV + RI > >>> extension in the ClientHello. > >> > >> That certainly sounds like a reasonably minor change to make. > > > > Full agreement. > > Except Marsh didn't say that. He said: > > > That certainly sounds like a reasonably minor change to make...but it > isn't. > > Which is totally different. Marsh made two statements: (1) it sounds like a reasonably minor change (2) Marsh thinks it is not a reasonably minor change I fully agree with the first. -Martin PS: could we please take discussions about style off-list? From mrex@sap.com Fri Dec 18 09:45: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 9D6A93A6983 for ; Fri, 18 Dec 2009 09:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 H71+SwlsciO7 for ; Fri, 18 Dec 2009 09:45: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 AEE863A6930 for ; Fri, 18 Dec 2009 09:45:46 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIHjQFG005593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 18:45:26 +0100 (MET) From: Martin Rex Message-Id: <200912181745.nBIHjPN5028573@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 18 Dec 2009 18:45:25 +0100 (MET) In-Reply-To: <4B2BAFAC.9020501@extendedsubset.com> from "Marsh Ray" at Dec 18, 9 10:37:00 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: rdugal@certicom.com, tls@ietf.org Subject: Re: [TLS] Updated 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: Fri, 18 Dec 2009 17:45:47 -0000 Marsh Ray wrote: > > Currently, the SCSV achieves its primary objective with a very simple > definition. It has "exactly the same semantics as an empty > 'renegotiation_info' extension". How about TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the server to perform a secure handshake and confirm this by sending TLS extension RI in ServerHello. This will also fix the awkward disconnect between the symbolic name of the SCSV and the current description of its semantics. -Martin From marsh@extendedsubset.com Fri Dec 18 10:10: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 6C6C03A67E6 for ; Fri, 18 Dec 2009 10:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FHTCS5kWmt1 for ; Fri, 18 Dec 2009 10:10:00 -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 B5BC93A63EB for ; Fri, 18 Dec 2009 10:10: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 1NLhGr-000FRK-K3; Fri, 18 Dec 2009 18:09:45 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AEFDE6678; Fri, 18 Dec 2009 18:09: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: U2FsdGVkX182XedMr8n2jc9ERpI3lJPfuHHdlvCIS34= Message-ID: <4B2BC565.7020406@extendedsubset.com> Date: Fri, 18 Dec 2009 12:09:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912181731.nBIHVYOG027690@fs4113.wdf.sap.corp> In-Reply-To: <200912181731.nBIHVYOG027690@fs4113.wdf.sap.corp> 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] Updated 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, 18 Dec 2009 18:10:01 -0000 Martin Rex wrote: > Marsh made two statements: > (1) it sounds like a reasonably minor change > (2) Marsh thinks it is not a reasonably minor change Yes, except that I said it wasn't a reasonably minor change to make which is slightly different than (2). > PS: could we please take discussions about style off-list? It's more correctness than style. I think it's quite on-topic considering that this WG is about a protocol for communications which must be perfect. Chopping up quotes below the level of whole sentences is not real helpful for productive discussions. It's like some sort of fragmentation attack. This whole discussion could be some sort of meta-recapitulation of the discussions we've had about the semantics of SCSV. Perhaps it foreshadows something positive? - Marsh From mrex@sap.com Fri Dec 18 09:30: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 E403F3A68D3 for ; Fri, 18 Dec 2009 09:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 INqJ6y5Avd2W for ; Fri, 18 Dec 2009 09:30: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 E99A928C0CF for ; Fri, 18 Dec 2009 09:30:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIHUDYl014493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 18:30:13 +0100 (MET) From: Martin Rex Message-Id: <200912181730.nBIHUC0O027649@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Fri, 18 Dec 2009 18:30:12 +0100 (MET) In-Reply-To: <4B2BBA78.8020702@cs.tcd.ie> from "Stephen Farrell" at Dec 18, 9 05:23:04 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 X-Mailman-Approved-At: Fri, 18 Dec 2009 10:28:54 -0800 Subject: Re: [TLS] Updated 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: Fri, 18 Dec 2009 17:30:32 -0000 Stephen Farrell wrote: > > Martin Rex wrote: > > Marsh Ray wrote: > >> Robert Dugal wrote: > >>> Oops, you're right. I misstated what I'd like the draft to allow. > >>> What I'd like is the option to always send the SCSV in the > >>> ClientHello and on renegotiation requests send the SCSV + RI > >>> extension in the ClientHello. > >> > >> That certainly sounds like a reasonably minor change to make. > > > > Full agreement. > > Except Marsh didn't say that. He said: > > > That certainly sounds like a reasonably minor change to make...but it > isn't. > > Which is totally different. Marsh made two statements: (1) it sounds like a reasonably minor change (2) Marsh thinks it is not a reasonably minor change I fully agree with the first. -Martin PS: could we please take discussions about style off-list? From mrex@sap.com Fri Dec 18 11:16: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 6821E3A6806 for ; Fri, 18 Dec 2009 11:16:52 -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 kWPzAVKb9gyt for ; Fri, 18 Dec 2009 11:16:51 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 361B03A67F1 for ; Fri, 18 Dec 2009 11:16:50 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBIJGYfl004996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 20:16:34 +0100 (MET) From: Martin Rex Message-Id: <200912181916.nBIJGXap003912@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Fri, 18 Dec 2009 20:16:33 +0100 (MET) In-Reply-To: <6b9359640912171745k3be3d9a9je84a449fd998dab0@mail.gmail.com> from "Kyle Hamilton" at Dec 17, 9 05:45:38 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] Summarizing identity change discussion so far 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, 18 Dec 2009 19:16:52 -0000 Kyle Hamilton wrote: > > On Thu, Dec 17, 2009 at 5:31 PM, Martin Rex wrote: > > The application was able to perform the initial authentication > > (log-on or ACL-check), so it is the duty of the application to > > perform any reauthentication in the very same fashion when > > renegotiation results in a different cert(chain).  Everything > > else will result in endless pain. > > > > > > ...and that is a reason why personally, I prefer that the necessity > > for cert renewal requires a new connection and full initial handshake-- > > because that is exaclty the code path which has all of the > > functionality and checks that we are looking for! > > I do agree with you there. Unless the saved session mechanism also > triggers the functionality and checks that a full handshake would, but > I think that's too much to hope for. This could be another potential security problem for an application. If the certficate path validation is only triggered during full handshakes (because it is somehow chained into the processing of the Certficate handshake message in a Callback-style), then a TLS implementation of TLS session resume might skip the certificate path validation (still providing the original certificate to the application), and the application might perform only the mapping (log-on, ACL-check) while assuming that the certificate path validation was automatically provided by the TLS implementation. In theory, TLS sessions get purged from the server-side session cache at some point in time, so the that the problem could be temporary. But depending on how the session cache expiration is implemented (based on time-of-creation vs. last-recently-used), there might be a possibility for a client to "touch" the cached session regularly, so that it will not be expired from a session cache that operates on last-recently-used, which may allow the client to skip certificate-path-validation (which would mean that expiration and revocation might be ignored for as long as the client can keep the session in the servers session cache). -Martin From mike-list@pobox.com Fri Dec 18 11: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 A215C3A6890 for ; Fri, 18 Dec 2009 11:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=1.067, 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 2DUuna1Vi-cI for ; Fri, 18 Dec 2009 11:24:16 -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 2E6833A6ABF for ; Fri, 18 Dec 2009 11:24:16 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E64EAA8588 for ; Fri, 18 Dec 2009 14:24:00 -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=4zgqQCJiltlR PKui7YVWrPQDNAc=; b=IHwojz6wQxacoI6g/d4vHgd4oa0pwzgKtHkNdV8SVuBk qrFeYNGWpJQ2CDMHgOiWbvYUu+tE96Wxx56/MHgX4S9lfOctc+9/q82z1jJnQ6k0 wQ5VPDcgyOGIVhMGFwWvBed2aiERJ6WA9CAh5awMFV5ruInEMcVg9mgRZ2+F5e4= 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=NIwlXN P0X6T2Bx7VnYRP4ghO+l1lhlRiSK5gzQ41S4EpHjhLnewuCdVRHzOJVMAakPq5W+ Y4ozrR2RFku35jPdGNNAISzhlI4Kh2VYXiv5JV0l4pfSiuerOz/zTvs8ATl6MtpP rNS+I9xvaEwpjd5B1E0x2Q6SBqpDJeamukg0Y= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E2468A8587 for ; Fri, 18 Dec 2009 14: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-sd.pobox.com (Postfix) with ESMTPSA id 5DEE3A8586 for ; Fri, 18 Dec 2009 14:24:00 -0500 (EST) Message-ID: <4B2BD73D.4050702@pobox.com> Date: Fri, 18 Dec 2009 11:25:49 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Mailing List References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <4B2A73C7.7030505@pobox.com> <7E1DF37F1F42AB4E877E492C308E6AC402EEEAF1@XCH57YKF.rim.net> <4B2B94C0.7080302@extendedsubset.com> <7E1DF37F1F42AB4E877E492C308E6AC402EEEC63@XCH57YKF.rim.net> <4B2BAFAC.9020501@extendedsubset.com> In-Reply-To: <4B2BAFAC.9020501@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E5518922-EC0A-11DE-9F3D-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Updated 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, 18 Dec 2009 19:24:18 -0000 A limousine pulls up in front of a busy nightclub in LA. A well-dressed couple emerge and approach the entrance. The bouncer greets them with a smile and says, "you two arrived in a Swanky Comfortable Stretch Vehicle; you must be very important, so please go right on in." Later, a beat-up Buick with one headlight out pulls up in front of the club. After tipping the valet, the driver approaches the entrance to the bar. The bouncer puffs his chest and stops the man from entering. "Where do you think you're going?" he asks. The man pulls something out of his pocket and shows it to the bouncer. "Oh, you have an invitation to the party; you must be Really Important, my apologies." Soon another limousine arrives and a Hollywood starlet gets out. When she reaches the bouncer, she hands him her invitation to the party. "Here you are, darling -- my invitation." "I'm sorry, but I can't let you in," replies the bouncer, "you are apparently Really Important, but you arrived in a Swanky Comfortable Stretch Vehicle, so I can't let you in." "Of all the.... I demand to speak to your manager, what is your name?" "My name is Xor, madam. May I suggest you ditch the limo and come back in a less- fancy car? We'll reconnect then, and I'll let you in." Mike Marsh Ray wrote: > Robert Dugal wrote: >> Oops, you're right. I misstated what I'd like the draft to allow. >> What I'd like is the option to always send the SCSV in the >> ClientHello and on renegotiation requests send the SCSV + RI >> extension in the ClientHello. > > That certainly sounds like a reasonably minor change to make...but it isn't. > > I don't recall seeing anyone propose wording changes that would allow > such behavior, except in the context of the other proposals which are > fundamentally different in that they modify the inputs to the PRF. It's > possible that some concrete wording was suggested and is in one of the > 1340 emails in my TLS folder. > > Currently, the SCSV achieves its primary objective with a very simple > definition. It has "exactly the same semantics as an empty > 'renegotiation_info' extension". > > IMHO, proponents of other semantics for SCSV should be able to produce > an equally straightforward description of what they are, or show > something truly magical to justify complicating the description. Saving > an 'if' statement somewhere, partially fixing a multiply-broken > scenario, or avoiding extensions handling in some non-general case don't > sound like they justify the extra complexity. > > Personally, I'd prefer that we don't propose (and re-propose) design > features at this point. We have to ship a fix for this open security > vulnerability, and I think the current design is squarely in the "good > enough" department. I.e. it fixes the problem and doesn't make anything > else significantly worse. > > If anyone sees a security flaw or attack against a correct > implementation of draft-ietf-tls-renegotiation-02, please please speak up. > > - Marsh From marsh@extendedsubset.com Fri Dec 18 11:31: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 C2FC73A6ABD for ; Fri, 18 Dec 2009 11:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy0GCs0GnMF7 for ; Fri, 18 Dec 2009 11:31:31 -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 9E6083A6ACB for ; Fri, 18 Dec 2009 11:31:31 -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 1NLiXk-000PzD-4E; Fri, 18 Dec 2009 19:31:16 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 170BB6678; Fri, 18 Dec 2009 19:31: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/9H588IuGnqxoDZQYSbE59yFiTDCQjGuQ= Message-ID: <4B2BD881.1050600@extendedsubset.com> Date: Fri, 18 Dec 2009 13:31:13 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912181745.nBIHjPN5028573@fs4113.wdf.sap.corp> In-Reply-To: <200912181745.nBIHjPN5028573@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: rdugal@certicom.com, tls@ietf.org Subject: [TLS] SCSV vs RI when both specified. Was: Updated 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, 18 Dec 2009 19:31:32 -0000 Martin Rex wrote: > Marsh Ray wrote: >> Currently, the SCSV achieves its primary objective with a very simple >> definition. It has "exactly the same semantics as an empty >> 'renegotiation_info' extension". > > How about > > TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the > server to perform a secure handshake and confirm this by sending > TLS extension RI in ServerHello. But what does that mean? What is "a secure handshake" if you're not sending the RI extension? To the extent that this document is describing how to perform a secure handshake, that definition is circular. So there are three cases with the SCSV: A. SCSV without RI extension. B. SCSV with empty RI extension. C. SCSV with non-empty RI extension. The current draft-ietf-tls-renegotiation-02 defines A as semantically equivalent to an empty RI extension. That appeals to me greatly, but it is certainly not the only way to look at it. Cases B and C are currently undefined AFAICT. We should fix this. Case B looks redundant under the current wording. RFC 3546 does not seem to say anything about multiple extensions of the same type. Case C looks like it's self-conflicting. So if I understand the current discussion correctly, it is about whether or not cases B and C are explicitly forbidden or explicitly allowed? == (I) Here's some proposed wording to fix the issue with in the favor of forbidding cases B and C: > Clients MUST NOT put multiple occurrences of an RI extension in the > same Client Hello message. Clients MUST NOT send the SCSV in the same > Client Hello message as any RI extension, not even an empty one. > > A server receiving a Client Hello containing multiple RI extensions > or the SCSV and one or more RI extensions MUST generate a fatal > "decode_error" alert and terminate the connection. == (II) Wording (which explicitly allows case B but forbids C: > Clients MUST NOT put multiple occurrences of an RI extension in the > same Client Hello message. A client MAY specify the SCSV in the same > Client Hello message as an empty RI extension, but MUST NOT specify > the SCSV in the same Hello as a non-empty RI. > > A server receiving a Client Hello containing multiple RI extensions > or the SCSV and one or more non-empty RI extensions MUST generate > a fatal "decode_error" alert and terminate the connection. We'll have to fix the conflict with the current: > This SCSV is not a true cipher suite and cannot be negotiated. It > merely has exactly the same semantics as an empty "renegotiation_info" > extension. to something like: > This SCSV is not a true cipher suite and cannot be negotiated, it > has similar semantics as an empty "renegotiation_info" extension. == (III) Wording which explicitly allows both cases B and C: > Clients MUST NOT put multiple occurrences of an RI extension in the > same Client Hello message. A client MAY specify the SCSV in the same > Client Hello message as an RI extension (the SCSV will be effectively > ignored). > > A server receiving a Client Hello containing multiple RI extensions > MUST generate a fatal "decode_error" alert and terminate the > connection. A server receiving a Client Hello containing the SCSV > and an RI extension is to interpret the RI as usual and ignore the > SCSV. We'll have to fix the conflict with the current: > This SCSV is not a true cipher suite and cannot be negotiated. It > merely has exactly the same semantics as an empty "renegotiation_info" > extension. to something like: > This SCSV is not a true cipher suite and cannot be negotiated, it > has similar semantics as an empty "renegotiation_info" extension. == Relative benefits. Clearly the current wording needs to be improved just a bit. My vote is for (I) because: * It allows a definition of the meaning of SCSV. * It involves the least wording change. * Fewer allowed combinations generally makes security easier to analyze. Cons of (I): * Implementers will have to set the SCSV pro programmatically. * Servers are required to be extra strict in what they accept. Pros of (II): * SCSV and empty RI together appear harmlessly redundant. Cons of (II): * Clients have flexibility which may surprise servers that weren't tested in all cases. * No good definition of what SCSV actually means. Pros of (III): * SCSV and empty RI together appear harmlessly redundant. * Clients can set-and-forget SCSV in all cases. Cons of (III): * Clients have flexibility which may surprise servers that weren't tested in all cases. * No good definition of what SCSV actually means. == Martin Rex wrote: > > This will also fix the awkward disconnect between the symbolic name of > the SCSV and the current description of its semantics. I feel consistent names are important too, but have avoided questioning that choice of names. Now - Marsh From mrex@sap.com Fri Dec 18 11:46: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 D89933A69D3 for ; Fri, 18 Dec 2009 11:46:06 -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 F9gL+P1f7iB2 for ; Fri, 18 Dec 2009 11:46:06 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C5B603A68FA for ; Fri, 18 Dec 2009 11:46:05 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBIJjn6i005606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Dec 2009 20:45:49 +0100 (MET) From: Martin Rex Message-Id: <200912181945.nBIJjnT8005613@fs4113.wdf.sap.corp> Orig-To: marsh@extendedsubset.com (Marsh Ray) To: tls@ietf.org Cc: tls@ietf.org Date: Fri, 18 Dec 2009 20:44:21 +0100 (MET) In-Reply-To: <4B2BD881.1050600@extendedsubset.com> from "Marsh Ray" at Dec 18, 9 01:31:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal08 X-SAP: out Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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: Fri, 18 Dec 2009 19:46:06 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Marsh Ray wrote: > >> Currently, the SCSV achieves its primary objective with a very simple > >> definition. It has "exactly the same semantics as an empty > >> 'renegotiation_info' extension". > > > > How about > > > > TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the > > server to perform a secure handshake and confirm this by sending > > TLS extension RI in ServerHello. > > But what does that mean? What is "a secure handshake" if you're not > sending the RI extension? To the extent that this document is describing > how to perform a secure handshake, that definition is circular. "A secure handshake" is one where client and server will check whether the contents of the TLS renegotiation RI match the verify_data from the Finished messages from the enclosing TLS session and TLS peers should abort the handshake if the conveyed information does not match. The presence of an empty TLS extension RI in ClientHello is obviated by presence of SCSV in this ClientHello handshake message. Do not try to describe scenarios. That is completely unecessary, very confusing and you may easily get the description of one of the cases wrong and cause confusion among implementors. The implementer's feedback was: In order to implement this MUST NOT I have to add two extra conditionals to the code, and I have to build test cases to check whether that doesn't break anything and whether I am compliant -- but in reality these two conditionals are completely useless, they do not add any value to the protocol and neither to the security. -Martin From nelson@bolyard.me Fri Dec 18 11:49: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 CB38E3A69D7 for ; Fri, 18 Dec 2009 11:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58GDwNwdugte for ; Fri, 18 Dec 2009 11:49:24 -0800 (PST) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id E61CC3A68FA for ; Fri, 18 Dec 2009 11:49:23 -0800 (PST) Received: (qmail 8183 invoked from network); 18 Dec 2009 19:49:08 -0000 Received: from unknown (24.5.142.42) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 18 Dec 2009 19:49:08 -0000 Message-ID: <4B2BDCAC.1040802@bolyard.me> Date: Fri, 18 Dec 2009 11:49: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: IETF TLS Working Group References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com><6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 19:49:24 -0000 On 2009-12-17 23:27 PST, Joseph Salowey (jsalowey) wrote: > I share the opinion that identity checking belongs in the application, > performed according to whatever mechanism is appropriate. We should not > be mandating any particular PKIX processing in the TLS specs. > > I also think if an application is not prepared to be aware of > renegotiation and handle any identity change associated with it then > renegotiation should be disabled. This implies that renegotiation > should be disabled by default and specifically enabled by an > application. So I would say > > "TLS implementations SHOULD disable renegotiation by default and offer > the applications the option to enable renegotiation. When an > application enables renegotiation it must handle identity processing for > each handshake." With my Idealist hat on, I agree with that 100%. But after 13.25 years of working on SSL/TLS libraries, I know that 98+% of the app developers who use TLS have no idea what that means or how to do it. IMO, they are likely to just call a function for each handshake that does the same thing as for the first handshake, validating the cert chain and (if we're lucky) checking that some aspect of the cert contains some expected name, without any regard to what prior certificates may have contained. So, IMO, it makes sense of TLS implementations to offer some sort of "default" handling of certs to attempt to ensure continuity of identity in the absence of something much better from the application. I'd suggest that, unless the applications direct them to do otherwise, perhaps by registering some callback, TLS implementations should check that the cert in a renegotiation is the same one as in the previous full handshake, either by memcmp of the entire cert, or by memcmp of the subject name and subjectAltName (if any). Anything less will ensure that most apps continue to get this wrong, IMO. From marsh@extendedsubset.com Fri Dec 18 12:13: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 C445328C105 for ; Fri, 18 Dec 2009 12:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpdKHYfQEI3g for ; Fri, 18 Dec 2009 12:13: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 D0E9A28C0F9 for ; Fri, 18 Dec 2009 12:13: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 1NLjC4-000JMq-L1 for tls@ietf.org; Fri, 18 Dec 2009 20:12:56 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 928586678 for ; Fri, 18 Dec 2009 20:12: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: U2FsdGVkX19rIp1rHi68nsCGCPEJ/sMGw6C3PJpjpPY= Message-ID: <4B2BE246.9040307@extendedsubset.com> Date: Fri, 18 Dec 2009 14:12:54 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tls@ietf.org" References: <200912181944.nBIJiLMU005565@fs4113.wdf.sap.corp> In-Reply-To: <200912181944.nBIJiLMU005565@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] SCSV vs RI when both specified. Was: Updated 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, 18 Dec 2009 20:13:12 -0000 Martin Rex wrote: > Marsh Ray wrote: >> Martin Rex wrote: >>> >>> TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the >>> server to perform a secure handshake and confirm this by sending >>> TLS extension RI in ServerHello. >> But what does that mean? What is "a secure handshake" if you're not >> sending the RI extension? To the extent that this document is describing >> how to perform a secure handshake, that definition is circular. > > "A secure handshake" is one where client and server will check > whether the contents of the TLS renegotiation RI match the > verify_data from the Finished messages from the enclosing TLS session > and TLS peers should abort the handshake if the conveyed information > does not match. The presence of an empty TLS extension RI in ClientHello > is obviated by presence of SCSV in this ClientHello handshake message. OK, let's see how that definition passes the substitution test: "TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the server to perform a handshake where client and server will check whether the contents of the TLS renegotiation RI match the verify_data from the Finished messages from the enclosing TLS session and TLS peers should abort the handshake if the conveyed information does not match and confirm this by sending TLS extension RI in ServerHello." Hmm, complete nonsense. That definition talks about how RI data is interpreted which is the antithesis of what SCSV is about. Come up with a way to complete a sentence that begins with "TLS_RENEGO_PROTECTION_REQUEST is" or "SCSV means" such that it describes the three cases for it in a reasonably consistent way. Real difficulties in doing this is, in my experience, a pretty good sign that something is wrong with a design. I think this is possible to do with wording (I) and much more challenging with the others. > Do not try to describe scenarios. That is completely unecessary, > very confusing and you may easily get the description of one of > the cases wrong and cause confusion among implementors. So you can't define SCSV, and I can't enumerate the scenarios where it can be used either? > The implementer's feedback was: > In order to implement this MUST NOT I have to add two extra conditionals > to the code, and I have to build test cases to check whether that doesn't > break anything and whether I am compliant -- but in reality these > two conditionals are completely useless, they do not add any value > to the protocol and neither to the security. I would build those test cases anyway. Having all cases defined and handled in an intentional way (even where they are defined to be ignored) is a good thing and inherently valuable. Perhaps nowhere more so than in the TLS initial hello handshaking. - Marsh From mike-list@pobox.com Fri Dec 18 12:35: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 804DB3A679C for ; Fri, 18 Dec 2009 12:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WBlT+UvZeTU for ; Fri, 18 Dec 2009 12:35: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 A539A3A688F for ; Fri, 18 Dec 2009 12:35: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 BDABF896B7 for ; Fri, 18 Dec 2009 15:35: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=YVmMHeGvcbR6 OPazEldYi3YNbsU=; b=b3FXhuq5eVl3la7B87Hyho0dR7dmhLcCbUPyIJQG9nmj BzFmM4FL4dP5Ogqk03vkRIMu3hfIsCdT9kNj2LrbQLXpGsom0iN9vuID6h/HapaM qSkh0xIpQXW8KK4HLYk4aciIGR6uQaE4MtobN1fOtOPK1+W+wJSD/O7TW8SBoGQ= 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=Dn13UO +DdKpCM6ztDxox+bHmNj6WyYEFxrmwJwrOPBgAcf/i52iLz6P6CP9IEJuxjGSjS1 mbgZRdS87GQKfKJOZFM4RcWvWEJnhPlmCYTILNYZAoIAgH3Z8IgrdzLxOxCmjNKD gB5658wtAru7BwD+cNGGpo36l1cmuEDUyR8No= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BA371896B6 for ; Fri, 18 Dec 2009 15:35: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-quonix.pobox.com (Postfix) with ESMTPSA id 656CC896B4 for ; Fri, 18 Dec 2009 15:35:11 -0500 (EST) Message-ID: <4B2BE7EC.7010309@pobox.com> Date: Fri, 18 Dec 2009 12:37:00 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Mailing List References: <200912181944.nBIJiLMU005565@fs4113.wdf.sap.corp> <4B2BE246.9040307@extendedsubset.com> In-Reply-To: <4B2BE246.9040307@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D6EFBD7C-EC14-11DE-9AA9-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 18 Dec 2009 20:35:29 -0000 Marsh Ray wrote: > Come up with a way to complete a sentence that begins with > "TLS_RENEGO_PROTECTION_REQUEST is" or "SCSV means" such that it > describes the three cases for it in a reasonably consistent way. "In the absence of an RI extension, SCSV conveys the same meaning as an empty RI. When RI is present, SCSV is ignored." Mike From mrex@sap.com Fri Dec 18 12:37: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 3A8F13A6A7D for ; Fri, 18 Dec 2009 12:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.453 X-Spam-Level: X-Spam-Status: No, score=-5.453 tagged_above=-999 required=5 tests=[AWL=-0.693, 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 q+t1EAmWGemN for ; Fri, 18 Dec 2009 12:37: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 DBAC23A67D1 for ; Fri, 18 Dec 2009 12:37:52 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBIKbP4x019127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 21:37:25 +0100 (MET) From: Martin Rex Message-Id: <200912182037.nBIKbN81008416@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com, Pasi.Eronen@nokia.com, ekr@networkresonance.com, jsalowey@cisco.com, nelson@bolyard.me Date: Fri, 18 Dec 2009 21:37:23 +0100 (MET) In-Reply-To: <4B2BC565.7020406@extendedsubset.com> from "Marsh Ray" at Dec 18, 9 12:09: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: [TLS] Apologies 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, 18 Dec 2009 20:37:54 -0000 Dear Marsh, Pasi, Eric, Joe, Nelson and several others, I want to apologize to you for having been a mean and offending a*****e at various times during the discussion on this list over the last 6 weeks. I really did not mean to slander on anyone's qualification as a software engineer, and I really envy everyone working for a smaller company than I do, for not having to wrangle with so many software logisitics processes as I'm facing in my work. I'm really only interested in the technology and want to provide value to my customers based on the technology developed in this forum, and since many of our customers are running pretty big intranet installations or our software that is connected to a lot of hardware controls (materials management, supply chain management, logistics) with a plethoria of devices I have never seen myself, I'm concerned about changes to this technology that may have an impact on the installed base of our customers. I assume that those long-standing key contributors to the TLS WG who were asked to join Project Mogul to help produce a solution to this serious vulnerability in the TLS protocol had to sign an NDA, and did not deliberately exclude the rest of us from the discussion. I could imagine that they felt quite uneasy about this situation. It is definitely not my intention to get in the way of providing a solution, I only want to help getting off some rough edges in the solution so that the likelyhood of casualties and severity of the damage out in field will be small. Some of the commercial providers have a lot of experience with the presence of TLS extensions in the products they ship, because they have been testing these capabilities over the course of several years. Evidently, it hasn't been easy for them either, visible from the availabilty of re-connect fallbacks to extension-less Hellos in pretty much all current apps that use TLS implementation capable of TLS extensions. For some of the mainstream consumers of this technology, and that includes us, sending out TLS extensions is a first. The third-party OEM SSL library that we acquired 10 years ago has never before sent out any TLS extensions, and none of our applications on top of it therefore has any re-connect fallback provisions that could be used if suddenly sending a TLS extension results in an interop problem. In difference to many other software vendors, we support our software for around 12 years (2 years of that is development, 10 years usage) on a platform, which is what our customers demand from us and for which they pay a non-negligible amount of maintenance fees. This time of active usage is often longer than the maintenance provided by the vendor of the underlying platform. It around 40 different hardware platforms and os-releases (32-bit and 64-bit where available) and includes fairly exotic platforms such as IBM OS/390 aka z/OS (an EBCDIC-platform, where our oldest supported OS-release still in use at our customers is OS/390 10.00), which was dropped out of vendor-support maybe 5 years ago. More mainstream platforms may be RedHat 6.1, OSF/1 4.0, Solaris 2.6. It's difficult to find an OEM who covers such a huge variety of platforms and for such a long time, long exceeding the maintenance of the OS vendors. Simply switching from one supplier to another is not an option, because the is much more to TLS than the wire-protocol. There are APIs, API-semantics, and most of all credentials and trust-anchor management and UIs around that. Dealing with the PKI-configuration and policy parts of the software is much more difficult and time-consuming that dealing with the TLS communication part. I would really apprececiate if we could get back to work and treat each other like professional engineers. Sincerely, -Martin Rex From marsh@extendedsubset.com Fri Dec 18 12:46: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 516353A6AD1 for ; Fri, 18 Dec 2009 12:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPBmJqYr9owc for ; Fri, 18 Dec 2009 12:46: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 989483A6ACD for ; Fri, 18 Dec 2009 12:46:18 -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 1NLji7-000J13-EK; Fri, 18 Dec 2009 20:46:03 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 514196678; Fri, 18 Dec 2009 20:46:02 +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/OMpUo6qi+kSDTTQYC5ogewb92WBeD9sc= Message-ID: <4B2BEA09.2030307@extendedsubset.com> Date: Fri, 18 Dec 2009 14:46:01 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <200912181944.nBIJiLMU005565@fs4113.wdf.sap.corp> <4B2BE246.9040307@extendedsubset.com> <4B2BE7EC.7010309@pobox.com> In-Reply-To: <4B2BE7EC.7010309@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 Mailing List Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 18 Dec 2009 20:46:19 -0000 Michael D'Errico wrote: > Marsh Ray wrote: >> Come up with a way to complete a sentence that begins with >> "TLS_RENEGO_PROTECTION_REQUEST is" or "SCSV means" such that it >> describes the three cases for it in a reasonably consistent way. > > "In the absence of an RI extension, SCSV conveys the same meaning > as an empty RI. When RI is present, SCSV is ignored." Hmmm...doesn't quite meet the stated requirements. - Marsh From mike-list@pobox.com Fri Dec 18 13:01: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 F2A413A6AC3 for ; Fri, 18 Dec 2009 13:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 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 HVcOWYkved9D for ; Fri, 18 Dec 2009 13:01: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 1A67A3A6AC2 for ; Fri, 18 Dec 2009 13:01: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 A614E89938 for ; Fri, 18 Dec 2009 16:01: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=A5Q+N88DpkD8 D5RaOGfUfnvasck=; b=c0ff00KLHd/n14H1TtvJCRZz0DhSMpj257+k/+Q05iOq M+aE1RxbDtTLQif2Ls9QaI8HEEnzZXtZfyCUU/I3pzT7BGEghBFBFVR4ENFS1KPl QmUfNCmnaMk4Iaam/Gq9asr/SkJ9V31L4GBKUDhRCl9IODpEtljygQQt3llJfOA= 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=QFNttK G2qUklIvg1wPAV5DRcmZOAqtUr0das02dC60W4Xw88oibkMJVYQ/tf8XFuZQWHgy J/23wofAiJkpOajxildmy5UOjMnYdhvMVoqFydDUxW3LqGwywVD8prEBODdOrLV6 Tu2mgRASgdI0EWFmb0PESdEV8XLKTDD/sklBw= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A308489937 for ; Fri, 18 Dec 2009 16:01: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-quonix.pobox.com (Postfix) with ESMTPSA id 40A1189936 for ; Fri, 18 Dec 2009 16:01:08 -0500 (EST) Message-ID: <4B2BEE01.90700@pobox.com> Date: Fri, 18 Dec 2009 13:02:57 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: TLS Mailing List References: <200912181944.nBIJiLMU005565@fs4113.wdf.sap.corp> <4B2BE246.9040307@extendedsubset.com> <4B2BE7EC.7010309@pobox.com> <4B2BEA09.2030307@extendedsubset.com> In-Reply-To: <4B2BEA09.2030307@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 76ECCD58-EC18-11DE-97B1-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 18 Dec 2009 21:01:28 -0000 Marsh Ray wrote: > Michael D'Errico wrote: >> Marsh Ray wrote: >>> Come up with a way to complete a sentence that begins with >>> "TLS_RENEGO_PROTECTION_REQUEST is" or "SCSV means" such that it >>> describes the three cases for it in a reasonably consistent way. >> "In the absence of an RI extension, SCSV conveys the same meaning >> as an empty RI. When RI is present, SCSV is ignored." > > Hmmm...doesn't quite meet the stated requirements. Because I used two sentences? Because I didn't start my sentence with "SCSV means"? My two sentences describe everything you need to know: SCSV absent, RI absent: hide the kids SCSV absent, RI present: same as RI SCSV present, RI absent: same as empty RI SCSV present, RI present: same as RI (SCSV ignored) Why do you want the last one to be "ABORT!!"? Mike From noskov@microsoft.com Fri Dec 18 13:31: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 18E4328C10C for ; Fri, 18 Dec 2009 13:31:24 -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 Ggz+rwRVy134 for ; Fri, 18 Dec 2009 13:31:21 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 321393A68C2 for ; Fri, 18 Dec 2009 13:31:21 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 18 Dec 2009 13:31:37 -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; Fri, 18 Dec 2009 13:31:04 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 18 Dec 2009 13:31:05 -0800 From: Nasko Oskov To: Peter Saint-Andre , Michael Gray Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: AQHKf2bXeOABEFFowEGB9UF9BHMAopFqWuCAgABGHQCAALI1AA== Date: Fri, 18 Dec 2009 21:30:32 +0000 Deferred-Delivery: Fri, 18 Dec 2009 21:31:00 +0000 Message-ID: References: <4B2AEDEE.30007@stpeter.im> In-Reply-To: <4B2AEDEE.30007@stpeter.im> 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 Cc: "tls@ietf.org" , Kyle Hamilton Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2009 21:31:24 -0000 UGV0ZXIgU2FpbnQtQW5kcmUgd3JvdGU6DQo+T24gMTIvMTcvMDkgMzozOSBQTSwgTWljaGFlbCBH cmF5IHdyb3RlOg0KPj4gbXJleEBzYXAuY29tIHdyb3RlOg0KPj4gDQo+PiBZZXMgdGhlIHByb2Js ZW0gaXMgZGVmaW5pbmcgd2hhdCBhbiBpZGVudGl0eSBjaGFuZ2UgaXMgcHJlY2lzZWx5LiAgV2Ug DQo+PiBrbm93IHRoYXQgQ0EncyBsb2FkIGFsbCBzb3J0cyBvZiBzdHVmZiBpbiB0byBjZXJ0aWZp Y2F0ZXMgYXMgcGFydCBvZiANCj4+IHRoZSBETiBldGMgYW5kIHRoZSBzYW1lIGlkZW50aWZ5IGNv dWxkIGhhdmUgbXVsdGlwbGUgY2VydGlmaWNhdGVzLCBhbmQgDQo+PiBjb3VsZCBiZSBpZGVudGlm aWVkIGJ5IG11bHRpcGxlIENBcy4gIElmIHdlIHNheSB0aGF0IGluIFRMUyB3ZSBhcmUgDQo+PiBn b2luZyB0byBjaGVjayBpZGVudGl0eSB0aGVuIGl0IGhhcyB0byBiZSB2ZXJ5IHByZWNpc2VseSBk ZWZpbmVkLCBvciANCj4+IGV4dHJlbWVseSB2YWd1ZWx5IGRlZmluZWQgc28gdGhhdCB0aGUgaW1w bGVtZW50YXRpb24gY2FuIG5vdCBiZSANCj4+IGFjY3VzZWQgb2Ygbm9uIGNvbXBsaWFuY2Ugb3Ig aW52YWxpZC9zdXNwZWN0IGlkZW50aXR5IG1hdGNoaW5nLiAgDQo+PiBQZXJoYXBzIGl0IG5lZWRz IHRvIGJlIGEgdmFndWUgYXMgcG9zc2libGUgc28gdGhhdCBUTFMgaW1wbGVtZW50YXRpb24gDQo+ PiBjYW4gc2ltcGx5IHB1c2ggaXQgYmFjayB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIgaW4gcHJh Y3RpY2UNCj4NCj5BcyBwcmV2aW91c2x5IGV4cHJlc3NlZCwgSSB0aGluayB0aGlzIGJlbG9uZ3Mg YXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLg0KDQpJIGFsc28gYWdyZWUgdGhhdCBpZGVudGl0eSBz aG91bGQgYmUgaGFuZGxlZCBieSB0aGUgYXBwbGljYXRpb24gbGF5ZXIsIGFzIGl0DQppcyBub3Qg c29tZXRoaW5nIFRMUyBpcyBiZXN0IHBvc2l0aW9uZWQgdG8gaGFuZGxlLg0KDQpOYXNrbw0K From mrex@sap.com Fri Dec 18 13:48: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 E0F573A68F4 for ; Fri, 18 Dec 2009 13:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 LvNubjYArmhq for ; Fri, 18 Dec 2009 13:48: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 8F5653A67F3 for ; Fri, 18 Dec 2009 13:48:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBILlxEo008480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 22:47:59 +0100 (MET) From: Martin Rex Message-Id: <200912182147.nBILlwv4012510@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 18 Dec 2009 22:47:58 +0100 (MET) In-Reply-To: <4B2BEE01.90700@pobox.com> from "Michael D'Errico" at Dec 18, 9 01:02: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] SCSV vs RI when both specified. Was: Updated 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: Fri, 18 Dec 2009 21:48:17 -0000 Michael D'Errico wrote: > > Marsh Ray wrote: > > Michael D'Errico wrote: > >> Marsh Ray wrote: > >>> Come up with a way to complete a sentence that begins with > >>> "TLS_RENEGO_PROTECTION_REQUEST is" or "SCSV means" such that it > >>> describes the three cases for it in a reasonably consistent way. > >> "In the absence of an RI extension, SCSV conveys the same meaning > >> as an empty RI. When RI is present, SCSV is ignored." > > > > Hmmm...doesn't quite meet the stated requirements. > > Because I used two sentences? Because I didn't start my sentence > with "SCSV means"? > > My two sentences describe everything you need to know: > > SCSV absent, RI absent: hide the kids > SCSV absent, RI present: same as RI > SCSV present, RI absent: same as empty RI > SCSV present, RI present: same as RI (SCSV ignored) > > Why do you want the last one to be "ABORT!!"? I think Marsh is looking for a descriptive text of the semantics of SCSV, instead of an implementation guidance what to do when -- that latter one is easy and intuitive to implementers, which is why Robert asked for this change in the first place. Personally, I feel it is much simpler to first describe the design of the solution at the abstract level, then see where SCSV fits in the abstract level. When doing that, everything falls in the right places all by itself. At the abstract level, the solution to the TLS renegotiation problem provided by TLS extension RI contains the following elements: briefest (where "required" means required for the solution to be secure) (1) required: mutually confirm that new handshake is available (2) optional: distinguish initial from renegotiation handshake (3) required: authenticate the enclosing TLS session during the renegotiation handshake brief: (a1a) Client->Server "Hi, I'm updated -- new handshake semantics please" (a1b) Server->Client "Good to hear, lets handshake securely" (a2a) Client->Server "this is an initial handshake" (a2b) Server->Client "this is an initial handshake (a3a) Client->Server "this is a renegotiation handshake" (a3b) Server->Client "this is a renegotiation handshake" (a4a) Client->Server "I want to renegotiate this previous TLS session" (a4b) Server->Client "I am renegotiating this previous TLS session" Let's look at the (spec-level) implementation details of the approach originally described in draft-ietf-rescorla-00: (i1a) implemented by presence of *any* RI in ClientHello (i1b) implemented by presence of *any* RI in ServerHello (i2a) implemented by _empty_ RI in ClientHello (i2b) implemented by _empty_ RI in ServerHello (i3a) implemented by non-empty RI in ClientHello (i3b) implemented by non-empty RI in ServerHello (i4a) implemented by RI with Client.Finished in ClientHello (i4b) implemented by RI with Client.Finished+ServerFinished in ServerHello Now let's add SCSV to the picture. SCSV in ClientHello can only convey a single bit of information (i1a), where as you can see above, empty RI in ClientHello actually conveys 2 bits of information (i1a) (i2a) because sometimes a complementary non-empty RI is used. Therefore describing SCSV as to mean an empty RI is inappropriate, because it DOES NOT mean that, SCSV is simply an alternative spec-level implementation of (a1a), something like (i1a'). If we use SCSV on extension-less ClientHellos or on SSLv2 ClientHellos then it only conveys (a1a), but not (a2a). Security-wise this is no problem, because the distinction of initial vs. renegotiation hanshake is an optional feature in the architecture, it is _NOT_ a criticial part to the design. Now if we compare the architecture and the resulting signaling when RI and SCSV are both part of the spec-level implementation: You describe the possible contents of ClientHello: (I) SCSV absent, RI absent: hide the kids (II) SCSV absent, RI present: same as RI (III) SCSV present, RI absent: same as empty RI (IV) SCSV present, RI present: same as RI (SCSV ignored) (I) describes the ClientHello from an old client (II) represents (i1a), and depending on the contents of RI additionally (i2a) or (i3a) (III) represents (i1a') (IV) represents (i1a') and depending on the contents of RI additionally (i2a) or (i3a) Marsh is questioning that (IV) makes sense. Let's check our architecture: What semantics has the combination of (a1a) and (a2a) according to the architecture of our solution: (a1a) Client->Server "Hi, I'm updated -- new handshake semantics please" (a2a) Client->Server "this is an initial handshake" What semantics has the combination of (a1a) and (a3a) according to the architecture of our soltion: (a1a) Client->Server "Hi, I'm updated -- new handshake semantics please" (a3a) Client->Server "this is a renegotiation handshake" I really do not see an problem with allowing (IV) for our architecture. So what is left is a simple matter of wordsmithing. -Martin From djhopwood@googlemail.com Fri Dec 18 19:54: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 8D6843A68A8 for ; Fri, 18 Dec 2009 19:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=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 F7fsnIEhaKPD for ; Fri, 18 Dec 2009 19:54:17 -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 8A6333A6824 for ; Fri, 18 Dec 2009 19:54:17 -0800 (PST) Received: by ewy6 with SMTP id 6so1096135ewy.29 for ; Fri, 18 Dec 2009 19:53: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=84UsUA0qA4qTI99cKMVh89pNrJ9Ecqj2YGwQxZUyMVY=; b=VfU6DtmdBqD+EzcaPl3+Eh5yhKWrrgSFLjvnhj2XTUOW4tb3qxX4Oii6vPLMBE6oG2 cbuo3Lu/upOBoBANqBo5UuBb7ZLc52mWGSc3MnKrKxKpg4iLTEAqbmA/AQgswE4k3MSy co5ruDtu85RBMD9BMDq420yJZwY+GxS4W0np4= 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=a1Ehu3CVlbpgvGVVy7n1VRZbg3Mrwo7r+FoqHIwPnpXvw3Momc6/if1x3CIOXSuPVL qxeRtpsGF1Kc0UVswPOsGvLTXFnseivNaGlAX/OlfX4OFmTYlzbFPVPxQy75Hoy3kxxe bMPyEZBcX1x1HHfoJY88TQ3bAvdoMjDw3a0gc= Received: by 10.213.26.199 with SMTP id f7mr2784516ebc.72.1261194838847; Fri, 18 Dec 2009 19:53:58 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 14sm2339891ewy.11.2009.12.18.19.53.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Dec 2009 19:53:57 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2C4E4E.8020208@jacaranda.org> Date: Sat, 19 Dec 2009 03:53: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: <3561bdcc0912172249i678bdbf5p89f1c3b3e8fd635@mail.gmail.com> In-Reply-To: <3561bdcc0912172249i678bdbf5p89f1c3b3e8fd635@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig591A489988C9C7B990B24AB9" Subject: Re: [TLS] TLS Digest, Vol 65, Issue 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: Sat, 19 Dec 2009 03:54:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig591A489988C9C7B990B24AB9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ravi Ganesan wrote: >> I do agree with you there. Unless the saved session mechanism also >> triggers the functionality and checks that a full handshake would, but= >> I think that's too much to hope for. >=20 > I know everyone on this thread knows otherwise, but the way the terms g= et > used, can easily result in confusion between "full handshake", "abbrevi= ated > handshake" and "renegotiated full handshake". The attack only applies = of > course to last category, and NOT to the abbreviated handshake. Well, it also applies to a renegotiated abbreviated handshake (where a renegotiating handshake resumes an existing session). The spec should probably point out that this case is possible, and that exactly the same attacks and defences apply. > To be pedantic, in the "full" handshake the two sides (or at least the > Server) prove identity to each other using their private keys and > certificates chaining to mutually trusted roots, and exchange the > "master_secret" which is really the "session key". This "master_secret"= can > be used by the "abbreviated handshake" to create many (including parall= el) > subsequent sessions with each party proving identity here by proving > possession of the session key (the "master secret"). During the abbrevi= ated > handshake one simply CANNOT do all the checks in the full handshake, no= t > because the developer chose not to do it, but because there is no quest= ion > of public key credentials...the abbreviated handshake is relying purely= on > the shared secret (via the server.verify and client.verify). It's relying on the fact that those checks were done correctly in the session that is being resumed. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig591A489988C9C7B990B24AB9 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/ iF4EAREIAAYFAkssTlQACgkQWUc8YzyzqAdcwAD/a3uFkxAa/I/EbiFULUoS5Dkh y31G+I8fVrZYB0A/N4wA/1K+4Ix/1c6S3KYTwI9oVsPBm8u/cqtXXIX2ajFe+EL7 =HHw4 -----END PGP SIGNATURE----- --------------enig591A489988C9C7B990B24AB9-- From djhopwood@googlemail.com Fri Dec 18 20: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 028F028C12B for ; Fri, 18 Dec 2009 20:07:20 -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 7myZ+XRh+ozW for ; Fri, 18 Dec 2009 20:07:19 -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 D9B3D3A67B1 for ; Fri, 18 Dec 2009 20:07:18 -0800 (PST) Received: by ewy6 with SMTP id 6so1100513ewy.29 for ; Fri, 18 Dec 2009 20:07: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=IcUFzpzsYDh2dp6ipGIV+sL0eV6nIbATZ180plygIOM=; b=xqJHvrvw0ljgXJN2xU6ZwxWtrcVABj0XxmCkV5PjCT5OYs3rlRwbWoe5bomTnEiAhN s9Db6amV0uLKjKVuAeyWW6QR+fO3QJFSzV36NrgtSfAq+7TJnHa4K7uvSVoYK8lGF6kk 7E6zvaJ3N0zCHLCBoRT9kIRv+CBY8MpB/YjI4= 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=lQXHKgJzGzKdyQVU/LG1YmKRbIUg7tZ4RucJdzCvC+s63ZP5q/Oazh1jA1qME/8Qrh MWjR1viGSnj7xeUTDVyFD8LuqhSCeJo/QaU5eg9ibS6tdHHRFO0VL4zsiJ4n6ivNdPS0 qhFqG87847m7RAowIeFMmdar8GKYyumwGH/4I= Received: by 10.213.107.17 with SMTP id z17mr5713473ebo.10.1261195620422; Fri, 18 Dec 2009 20:07:00 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 7sm6344824eyb.34.2009.12.18.20.06.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Dec 2009 20:06:58 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2C515B.7000604@jacaranda.org> Date: Sat, 19 Dec 2009 04:06: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: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854006@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854006@LLE2K7-BE01.mitll.ad.local> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig341D454F20947160714F6E18" Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 04:07:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig341D454F20947160714F6E18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blumenthal, Uri - 0662 - MITLL wrote: > Kyle Hamilton wrote: >> On Tue, Dec 8, 2009 at 1:13 AM, wrote: >>> (wearing Area Director hat) >>> >>> - We recommend that TLS libraries SHOULD provide identity matching >>> (with memcmp, abort handshake if changed) functionality to >>> applications, and SHOULD allow applications to enable/disable this >>> functionality. >> No, identity matching SHOULD be done in accordance with PKIX. >=20 > Strongly disagree. If implementations try to do identity matching that > is any more complicated than memcmp then they *will* get it wrong; see > for evidence. > > My strong conviction is that the fact of non-zero probability to get > (e.g.) PKIX identity matching wrong - does NOT invalidate the need for > something more powerful and usable than memcmp. I'm not convinced that > MD5 collision exploitation justifies restriction of matching to memcmp.= There are numerous independent bugs related to name matching described in that paper; I wasn't referring specifically to the MD5 issue. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig341D454F20947160714F6E18 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/ iF4EAREIAAYFAkssUWEACgkQWUc8YzyzqAeuFwD+O73AhouPP0Ts77nZA1eFp1H+ tg1WRUd1Tbux+1NiqGwA/Rf62BAcP+BMen6z4VQUBavAaXCHm/PWT8R4iVLNt3Es =gljY -----END PGP SIGNATURE----- --------------enig341D454F20947160714F6E18-- From djhopwood@googlemail.com Fri Dec 18 20:47: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 745263A687B for ; Fri, 18 Dec 2009 20:47:05 -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 XDQBKjivRQsG for ; Fri, 18 Dec 2009 20:47:04 -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 3D3C43A67CC for ; Fri, 18 Dec 2009 20:47:04 -0800 (PST) Received: by ewy6 with SMTP id 6so1112747ewy.29 for ; Fri, 18 Dec 2009 20:46: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=AAigQmFX015ExVnjnd1V4eU6CTyOSw3QqhQ5sjjGs+s=; b=jrmFPfiLalOK3KOv8HqRBJTRlypYT1kV3B7ILaEkEFgyspVnyaqoujuIfnCrLzeigS 5EezCNI1jQ8Sip3eMnBYwycHQ2xY3In1wbyn67ZpzvMNbUVm/mh1GYypZRMVoAsfm93C 1quT1EFto9PgTylSgPNFs1yHu8HU1b7e1ok2g= 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=orSf7pm0ZR7nhZRZ7VtLj57WhtmpjBEKiKUeQpOZ29Dlbe0/cLr1tdgLrafNvw0dpV e8VwS1XR82VBrRNxtHKfUXijAEZoGiHRc0jUclKaXNq1QQtR1GUfCJzGh+MwWfjmIkuw SyMiClhhwh6QfJLLSlsq8Ng9dymQslswDt314= Received: by 10.213.51.3 with SMTP id b3mr5483173ebg.31.1261198005316; Fri, 18 Dec 2009 20:46:45 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 13sm2356702ewy.13.2009.12.18.20.46.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Dec 2009 20:46:44 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2C5AB3.5050404@jacaranda.org> Date: Sat, 19 Dec 2009 04:46: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: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854006@LLE2K7-BE01.mitll.ad.local> <4B2C515B.7000604@jacaranda.org> In-Reply-To: <4B2C515B.7000604@jacaranda.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig00370184C749D04A207CBD30" Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 04:47:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00370184C749D04A207CBD30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [I messed up the attributions in the previous post -- fixed below.] Blumenthal, Uri - 0662 - MITLL wrote: > David-Sarah Hopwood wrote: >> Kyle Hamilton wrote: >>> On Tue, Dec 8, 2009 at 1:13 AM, wrote: >>>> (wearing Area Director hat) >>>> >>>> - We recommend that TLS libraries SHOULD provide identity matching >>>> (with memcmp, abort handshake if changed) functionality to >>>> applications, and SHOULD allow applications to enable/disable this >>>> functionality. >>> >>> No, identity matching SHOULD be done in accordance with PKIX. >> >> Strongly disagree. If implementations try to do identity matching that= >> is any more complicated than memcmp then they *will* get it wrong; see= >> for evidence. > > My strong conviction is that the fact of non-zero probability to get > (e.g.) PKIX identity matching wrong - does NOT invalidate the need for > something more powerful and usable than memcmp. I'm not convinced that > MD5 collision exploitation justifies restriction of matching to memcmp.= There are numerous independent bugs related to name matching described in that paper; I wasn't referring specifically to the MD5 issue. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig00370184C749D04A207CBD30 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/ iF4EAREIAAYFAkssWrMACgkQWUc8YzyzqAe8ogD9G0IhdPAIRcIWJriDFy0MdaF8 Nzi1S54546i7gSbO2GMA/iFBdnQsD43g7Sqc58q2819QpqRoJVPmN290rlUzsMwU =vs7I -----END PGP SIGNATURE----- --------------enig00370184C749D04A207CBD30-- From jsalowey@cisco.com Fri Dec 18 22: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 6ED733A68A7 for ; Fri, 18 Dec 2009 22:03:29 -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 Xs4NaksmnJ15 for ; Fri, 18 Dec 2009 22:03:28 -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 7089B3A6887 for ; Fri, 18 Dec 2009 22:03:28 -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: ApoEAGP7K0urR7Ht/2dsb2JhbAC+WZZ9gi+BfwQ X-IronPort-AV: E=Sophos;i="4.47,422,1257120000"; d="scan'208";a="65093292" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 19 Dec 2009 06:03:13 +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 nBJ63DYn023701; Sat, 19 Dec 2009 06:03:13 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); Fri, 18 Dec 2009 22:03: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: Fri, 18 Dec 2009 22:03:12 -0800 Message-ID: In-Reply-To: <4B2BDCAC.1040802@bolyard.me> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: AcqAGzeDAkldwC8qQjWRqwGgxqQqxQAVK08Q References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com><6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> <4B2BDCAC.1040802@bolyard.me> From: "Joseph Salowey (jsalowey)" To: "Nelson B Bolyard" , "IETF TLS Working Group" X-OriginalArrivalTime: 19 Dec 2009 06:03:13.0679 (UTC) FILETIME=[F31AC1F0:01CA8070] Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 06:03:29 -0000 =20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Nelson B Bolyard > Sent: Friday, December 18, 2009 11:49 AM > To: IETF TLS Working Group > Subject: Re: [TLS] Summarizing identity change discussion so far >=20 > On 2009-12-17 23:27 PST, Joseph Salowey (jsalowey) wrote: > > I share the opinion that identity checking belongs in the=20 > application,=20 > > performed according to whatever mechanism is appropriate. =20 > We should=20 > > not be mandating any particular PKIX processing in the TLS specs. > >=20 > > I also think if an application is not prepared to be aware of=20 > > renegotiation and handle any identity change associated=20 > with it then=20 > > renegotiation should be disabled. This implies that renegotiation=20 > > should be disabled by default and specifically enabled by an=20 > > application. So I would say > >=20 > > "TLS implementations SHOULD disable renegotiation by=20 > default and offer=20 > > the applications the option to enable renegotiation. When an=20 > > application enables renegotiation it must handle identity=20 > processing=20 > > for each handshake." >=20 > With my Idealist hat on, I agree with that 100%. But after=20 > 13.25 years of working on SSL/TLS libraries, I know that 98+%=20 > of the app developers who use TLS have no idea what that=20 > means or how to do it. IMO, they are likely to just call a=20 > function for each handshake that does the same thing as for=20 > the first handshake, validating the cert chain and (if we're > lucky) checking that some aspect of the cert contains some=20 > expected name, without any regard to what prior certificates=20 > may have contained. > > > So, IMO, it makes sense of TLS implementations to offer some=20 > sort of "default" handling of certs to attempt to ensure=20 > continuity of identity in the absence of something much=20 > better from the application. I'd suggest that, unless the=20 > applications direct them to do otherwise, perhaps by=20 > registering some callback, TLS implementations should check=20 > that the cert in a renegotiation is the same one as in the=20 > previous full handshake, either by memcmp of the entire cert,=20 > or by memcmp of the subject name and > subjectAltName (if any). Anything less will ensure that=20 > most apps continue > to get this wrong, IMO. [Joe] So ideally renegotiation would be disabled (perhaps after the client is authenticated in a TLS handshake) unless application enables it. The TLS implementation can implement some policy on how to match identity from on handshake to the next, but I'm not confident that any single specific policy will be the right policy for different applications and deployments.=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From s@pahtak.org Sat Dec 19 00:47: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 2F83B3A6A2E for ; Sat, 19 Dec 2009 00:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaLgKRtIKB+C for ; Sat, 19 Dec 2009 00:47:07 -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 4DF2B3A6967 for ; Sat, 19 Dec 2009 00:47:07 -0800 (PST) Received: by gxk28 with SMTP id 28so3704306gxk.9 for ; Sat, 19 Dec 2009 00:46:49 -0800 (PST) Received: by 10.150.48.29 with SMTP id v29mr6028385ybv.200.1261212409640; Sat, 19 Dec 2009 00:46:49 -0800 (PST) Received: from lonely.pahtak.org (ip68-107-82-55.sd.sd.cox.net [68.107.82.55]) by mx.google.com with ESMTPS id 22sm2816341iwn.4.2009.12.19.00.46.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 19 Dec 2009 00:46:48 -0800 (PST) Received: from dualg5.pahtak.org (dualg5.pahtak.org [192.168.1.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by lonely.pahtak.org (Postfix) with ESMTPSA id 5D9F25C26D; Sat, 19 Dec 2009 00:46:46 -0800 (PST) Message-Id: <668916E2-787C-44B2-9577-707FD1611E45@pahtak.org> From: Steve Checkoway To: TLS Mailing List In-Reply-To: <4B2BEE01.90700@pobox.com> Content-Type: multipart/signed; boundary=Apple-Mail-25--562635596; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 19 Dec 2009 00:46:45 -0800 References: <200912181944.nBIJiLMU005565@fs4113.wdf.sap.corp> <4B2BE246.9040307@extendedsubset.com> <4B2BE7EC.7010309@pobox.com> <4B2BEA09.2030307@extendedsubset.com> <4B2BEE01.90700@pobox.com> X-Mailer: Apple Mail (2.936) Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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: Sat, 19 Dec 2009 08:47:08 -0000 --Apple-Mail-25--562635596 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 18, 2009, at 1:02 PM, Michael D'Errico wrote: > My two sentences describe everything you need to know: > > SCSV absent, RI absent: hide the kids > SCSV absent, RI present: same as RI > SCSV present, RI absent: same as empty RI > SCSV present, RI present: same as RI (SCSV ignored) > > Why do you want the last one to be "ABORT!!"? It's pretty clear (to me) that it doesn't matter if the last one is allowed or not, as long as the spec makes a clear decision. It's roughly the same amount of code (plus or minus a conditional and an alert). The four conditions have to be tested regardless of how it's defined. Is this point really so important that it's worth holding up publication and subsequent implementation? I say it is not. -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier --Apple-Mail-25--562635596 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGGTCCAtIw ggI7oAMCAQICECjZEESO561wLe6hSYyS4IQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDkyNTA2MTQwNVoXDTEwMDkyNTA2MTQw NVowPjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMc0Bw YWh0YWsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7p9cy3FSDC8pQp2wZJk szOqOD5o56n9IXludNRnvM1qxXy/axIE5oFiJvrOEB4fZhMiuP8HAM74NJqUGSTl3aNXBVgwVRbW i+COSpfmObxiK3UFA/T2sn6cPLpJEFjY5TvekVEKLNAi2k4iIUw8BreHWZ1xnGAUA6Z/UbQoHI6c Vl/Rcu1dWNWTwCyUNYwX09JMFu0B9RQ09ltiZhjDurUG9Zt2qSIy8G4ptEtlYqibL2ugs0wW/Hkf PQadgqlt5V52WOFtObn+dcJxvnZ2b8goUaFRHaALidyEARSUJoZRrj0rCKOIkLhH8oU5bfoJ1X5p BaW/w5rU5WqfrEIC2QIDAQABoykwJzAXBgNVHREEEDAOgQxzQHBhaHRhay5vcmcwDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQUFAAOBgQA5NBSpsqBLU41YA9IQ8Ojqz5K7MSyVo2q3Amv/pQlmyPxw tAWfAeujwxgeZ1hlfLDWotLOkUr1QJDY+ouRg1c7v0hwdOrr1WYF2as/7XY3i7sJE9WxNbBbm8rc u5/OMrbIwb+JH4fX/EhzAZtUJfNqkoUIg9zSW8kESEJP/Gr+oTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQKNkQRI7nrXAt7qFJjJLghDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMTkwODQ2NDZaMCMGCSqGSIb3 DQEJBDEWBBRexItsz4+0+obdHxsT4rXNg0UdczCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECjZEESO561wLe6hSYyS4IQwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC ECjZEESO561wLe6hSYyS4IQwDQYJKoZIhvcNAQEBBQAEggEAVOg5XOiQowlIVCdFpfZ1ctRvlZdi c7XGoRXVKYY+Krl8DpRPz4tvqxh+qDQYhgWZn0wueaqHFanZN68KstMCPsQjSfViBa9QS6ZIsOmY knrzePJ/5o91Lg5XFo8dIJ2Wn89quSe7GR/pxqOZWN3kvtRoQIMHXEV4L/F3/gixc9gSxgdNGP1+ FFTENe5aVobyd8PngFbjPE+sTGMJpAkkJMANQnP5fl+lZkBeOcT3ZppViUgSoFOtHOFcbdhDEyb7 1v9UGMlSFkEK+4jnHJqTKFbsNgqozwSC1t3mOQS0KWJWzYU0e+FWMJKLgoh2qpJ5Z0T9ENKSykJ1 zqB4iuY77QAAAAAAAA== --Apple-Mail-25--562635596-- From uri@ll.mit.edu Sat Dec 19 05: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 A2C8F3A68B3 for ; Sat, 19 Dec 2009 05:28:11 -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 W+k1IENj11EX for ; Sat, 19 Dec 2009 05:28:10 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id BBB623A6953 for ; Sat, 19 Dec 2009 05:28:10 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBJDRrQf028581 for ; Sat, 19 Dec 2009 08:27:53 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAA54aya2; Sat Dec 19 08:24:15 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Sat, 19 Dec 2009 08:24:15 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Sat, 19 Dec 2009 08:24:14 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqAh9cpjxcz0TqVTsK1VI3qDexK4gAJrfWS Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE85400B@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] SCSV vs RI when both specified. Was: Updated 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: Sat, 19 Dec 2009 13:28:11 -0000 WW91J3JlIHNheWluZyBpdCdzIG5vdCBpbXBvcnRhbnQgd2hldGhlciB0aGUgcHJvdG9jb2wgc3Bl YyBkZW1hbmRzIGFib3J0aW5nIHRoZSBjb25uZWN0aW9uIG9yIG5vdD8hICBBcyBsb25nIGFzIHRo ZSBwcm9jZXNzaW5nIGFtb3VudCB0byBhcnJpdmUgYXQgdGhlIGRlY2lzaW9uIGlzIGFib3V0IHRo ZSBzYW1lPw0KDQpBbmQgeWVzIEkgd291bGQgaG9sZCB0aGUgcHVibGljYXRpb24gdG8gY2xlYXIg dXAgdGhpcyBpc3N1ZS4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxz LWJvdW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IFRMUyBNYWlsaW5n IExpc3QgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IFNhdCBEZWMgMTkgMDM6NDY6NDUgMjAwOQpTdWJq ZWN0OiBSZTogW1RMU10gU0NTViB2cyBSSSB3aGVuIGJvdGggc3BlY2lmaWVkLiBXYXM6IFVwZGF0 ZWQgZHJhZnQNCg0KDQpPbiBEZWMgMTgsIDIwMDksIGF0IDE6MDIgUE0sIE1pY2hhZWwgRCdFcnJp Y28gd3JvdGU6DQoNCj4gTXkgdHdvIHNlbnRlbmNlcyBkZXNjcmliZSBldmVyeXRoaW5nIHlvdSBu ZWVkIHRvIGtub3c6DQo+DQo+ICAgU0NTViBhYnNlbnQsICBSSSBhYnNlbnQ6ICAgaGlkZSB0aGUg a2lkcw0KPiAgIFNDU1YgYWJzZW50LCAgUkkgcHJlc2VudDogIHNhbWUgYXMgUkkNCj4gICBTQ1NW IHByZXNlbnQsIFJJIGFic2VudDogICBzYW1lIGFzIGVtcHR5IFJJDQo+ICAgU0NTViBwcmVzZW50 LCBSSSBwcmVzZW50OiAgc2FtZSBhcyBSSSAoU0NTViBpZ25vcmVkKQ0KPg0KPiBXaHkgZG8geW91 IHdhbnQgdGhlIGxhc3Qgb25lIHRvIGJlICJBQk9SVCEhIj8NCg0KDQpJdCdzIHByZXR0eSBjbGVh ciAodG8gbWUpIHRoYXQgaXQgZG9lc24ndCBtYXR0ZXIgaWYgdGhlIGxhc3Qgb25lIGlzICANCmFs bG93ZWQgb3Igbm90LCBhcyBsb25nIGFzIHRoZSBzcGVjIG1ha2VzIGEgY2xlYXIgZGVjaXNpb24u IEl0J3MgIA0Kcm91Z2hseSB0aGUgc2FtZSBhbW91bnQgb2YgY29kZSAocGx1cyBvciBtaW51cyBh IGNvbmRpdGlvbmFsIGFuZCBhbiAgDQphbGVydCkuIFRoZSBmb3VyIGNvbmRpdGlvbnMgaGF2ZSB0 byBiZSB0ZXN0ZWQgcmVnYXJkbGVzcyBvZiBob3cgaXQncyAgDQpkZWZpbmVkLg0KDQpJcyB0aGlz IHBvaW50IHJlYWxseSBzbyBpbXBvcnRhbnQgdGhhdCBpdCdzIHdvcnRoIGhvbGRpbmcgdXAgIA0K cHVibGljYXRpb24gYW5kIHN1YnNlcXVlbnQgaW1wbGVtZW50YXRpb24/IEkgc2F5IGl0IGlzIG5v dC4NCg0KLS0gDQpTdGV2ZSBDaGVja293YXkNCg0KICAgICAiQW55b25lIHdobyBzYXlzIHRoYXQg dGhlIHNvbHV0aW9uIGlzIHRvIGVkdWNhdGUgdGhlIHVzZXJzDQogICAgIGhhc24ndCBldmVyIG1l dCBhbiBhY3R1YWwgdXNlci4iIC0tIEJydWNlIFNjaG5laWVyDQoNCg0KDQoNCg== From ravi@findravi.com Sat Dec 19 09:13: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 9FBBD3A698F for ; Sat, 19 Dec 2009 09:13:42 -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.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3Vr+IzkMm2rv for ; Sat, 19 Dec 2009 09:13:37 -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 A57D03A6B24 for ; Sat, 19 Dec 2009 09:13:32 -0800 (PST) Received: by pzk6 with SMTP id 6so2943439pzk.29 for ; Sat, 19 Dec 2009 09:13:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.237.37 with SMTP id k37mr3527839wah.31.1261242794988; Sat, 19 Dec 2009 09:13:14 -0800 (PST) Date: Sat, 19 Dec 2009 09:13:14 -0800 Message-ID: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e64b95b6c55414047b17f870 Subject: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 17:13:42 -0000 --0016e64b95b6c55414047b17f870 Content-Type: text/plain; charset=UTF-8 > > > Ravi Ganesan wrote: > > > I know everyone on this thread knows otherwise, but the way the terms get > > used, can easily result in confusion between "full handshake", > "abbreviated > > handshake" and "renegotiated full handshake". The attack only applies of > > course to last category, and NOT to the abbreviated handshake. > > Well, it also applies to a renegotiated abbreviated handshake (where a > renegotiating handshake resumes an existing session). The spec should > probably point out that this case is possible, and that exactly the same > attacks and defences apply. > > David-Sarah Hopwood ? http://davidsarah.livejournal.com > > This may be my ignorance, but I assumed the purpose of renegotiation was a fresh exchange of authentication and/or keying material. The renego for instance can (infamously) require client-auth while the original did not. Or switch ciphersuites. The abbreviated handshake cannot achieve any of this. It does not involve certs or ciphersuites. I thought historically its purpose versus: the full handshake exchanges the master-secret in the context of a particular TCP-socket. If the Client wants to use that same master secret in the context of a new ( or a million parallel) TCP sockets, then use the abbreviated handshake (avoiding the PKI heavy lifting). The same thing applies if the binding underneath is not TCP. The abbreviated handshake really has only one purpose in life -- it binds the new SSL session (say the new TCP socket) to the old one, by each party proving knowledge of the original master secret. (exactly what the renegotiated handshake chose not to do). Examples would be a messengering client that negotiates a full handshake with a switch and then each time a new socket is opened for a new message uses the abbreviated handshake. Or a page with many many SSL protected objects that are independently retrieved. So in this context a "renegotiated abbreviated handshake" seems strange. But regardless even if there is something in existence called a "renegotiated abbreviated handshake", I think the distinction between 'abbreviated handshakes without renegoitation' which are very very widely used should not be confused with 'renegotiated handshakes of any kind'. It would be very helpful if the draft made this point. --0016e64b95b6c55414047b17f870 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ravi Ganesan wrote:

> I know everyone on this thread knows otherwise, but the way the terms = get
> used, can easily result in confusion between "full handshake"= ;, "abbreviated
> handshake" and "renegotiated full handshake". =C2=A0The= attack only applies of
> course to last category, and NOT to the abbreviated handshake.

Well, it also applies to a renegotiated abbreviated handshake (where a
renegotiating handshake resumes an existing session). The spec should
probably point out that this case is possible, and that exactly the same attacks and defences apply.

David-Sarah Hopwood =C2=A0? =C2=A0http://davidsarah.livejournal.com


This may be=C2=A0 my ignorance, but I assumed the pu= rpose of renegotiation was a fresh exchange of authentication and/or keying= material. The renego for instance can (infamously) require client-auth whi= le the original did not. Or switch ciphersuites.

The abbreviated handshake cannot achieve any of this. It does not invol= ve certs or ciphersuites.=C2=A0 I thought historically its purpose versus: = the full handshake exchanges the master-secret in the context of a particul= ar TCP-socket. If the Client wants to use that same master secret in the co= ntext of a new ( or a million parallel) TCP sockets, then use the abbreviat= ed handshake (avoiding the PKI heavy lifting). The same thing applies if th= e binding underneath is not TCP.=C2=A0 The abbreviated handshake really has= only one purpose in life -- it binds the new SSL session (say the new TCP = socket) to the old one, by each party proving knowledge of the original mas= ter secret. (exactly what the renegotiated handshake chose not to do).

Examples=C2=A0 would=C2=A0 be a messengering client that negotiates a f= ull handshake with a switch and then each time a new socket is opened for a= new message uses the abbreviated handshake. Or a page with many many SSL p= rotected objects that are independently retrieved.=C2=A0 So in this context= a "renegotiated abbreviated handshake" seems strange.

But regardless even if there is something in existence called a "r= enegotiated abbreviated handshake", I think the distinction between &#= 39;abbreviated handshakes without renegoitation' which are very very wi= dely used should not be confused with 'renegotiated handshakes of any k= ind'.

It would be very helpful if the draft made this point.


--0016e64b95b6c55414047b17f870-- From marsh@extendedsubset.com Sat Dec 19 11:00: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 A2EAF3A67DB for ; Sat, 19 Dec 2009 11:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzzd7yyslsgW for ; Sat, 19 Dec 2009 11:00:38 -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 24E333A672E for ; Sat, 19 Dec 2009 11:00:38 -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 1NM4XO-0005P5-Ge; Sat, 19 Dec 2009 19:00:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8F8526678; Sat, 19 Dec 2009 19:00: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: U2FsdGVkX1++rK0pCo1VSg2bW+phYOeGSpxrMrOILXY= Message-ID: <4B2D22C6.9090109@extendedsubset.com> Date: Sat, 19 Dec 2009 13:00:22 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ravi Ganesan References: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> In-Reply-To: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@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] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 19:00:39 -0000 Ravi Ganesan wrote: > > Well, it also applies to a renegotiated abbreviated handshake (where a > renegotiating handshake resumes an existing session). The spec should > probably point out that this case is possible, and that exactly the same > attacks and defences apply. > > David-Sarah Hopwood ? http://davidsarah.livejournal.com > > > This may be my ignorance, but I assumed the purpose of renegotiation > was a fresh exchange of authentication and/or keying material. Forget 'purpose', that's largely an application layer thing. The TLS spec defines mechanisms: what MAY, SHOULD, and MUST happen. Whether it's freshening keys, changing auth, etc. what others do with a basic feature like renegotiation is up to them. > The > renego for instance can (infamously) require client-auth while the > original did not. Or switch ciphersuites. My belief is that that was one of the original intended purposes for renegotiation: allow Netscape clients and servers to handle per-directory client certificate and crypto configuration. > The abbreviated handshake cannot achieve any of this. It does not > involve certs or ciphersuites. Sure, why not? Why couldn't a client offer resumption of a previously client-authed session in response to a server-initiated renegotiation? > I thought historically its purpose > versus: the full handshake exchanges the master-secret in the context of > a particular TCP-socket. No, that's the mechanism. > If the Client wants to use that same master > secret in the context of a new ( or a million parallel) TCP sockets, > then use the abbreviated handshake (avoiding the PKI heavy lifting). Saving computation is probably the most common use of session resumption. > The > same thing applies if the binding underneath is not TCP. The > abbreviated handshake really has only one purpose in life -- it binds > the new SSL session (say the new TCP socket) to the old one, Sort of. If the resumption is successful, it ends up being just one session which is instantiated on multiple connections. I haven't heard anyone thinking of it so much in terms of "binding" two TCP connections. Since you can't usually guarantee that session resumption will be successful, application protocols usually don't give it any semantic meaning. > by each > party proving knowledge of the original master secret. (exactly what the > renegotiated handshake chose not to do). A renegotiation handshake can resume a session if client and server agree on it. > Examples would be a messengering client that negotiates a full > handshake with a switch and then each time a new socket is opened for a > new message uses the abbreviated handshake. Or a page with many many SSL > protected objects that are independently retrieved. So in this context > a "renegotiated abbreviated handshake" seems strange. It's not clear what the use case is for doing session resumption on a renegotiation. But it really just falls naturally out of the basic design of TLS. The spec doesn't have to call it out as a special case. > But regardless even if there is something in existence called a > "renegotiated abbreviated handshake", I think the distinction between > 'abbreviated handshakes without renegoitation' which are very very > widely used should not be confused with 'renegotiated handshakes of any > kind'. Nowhere in the draft does it talk about "abbreviated handshakes". Whether or not a handshake is "abbreviated" has absolutely nothing to do with whether or not it is an initial or a renegotiation handshake. You could just as easily single out some other protocol feature, say Diffie-Hellman key exchange, and say there's an under-appreciated distinction between initial DH handshakes and every other kind of handshake. > It would be very helpful if the draft made this point. The bug and the fix are about renegotiation and have absolutely nothing to do with session resumption. Nevertheless, we already reiterate this point a couple of times in the draft. http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt: "The above rules apply even when TLS session resumption is used." "... with every ClientHello, including ClientHellos where session resumption is being offered." - Marsh From ravi@findravi.com Sat Dec 19 13:43: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 6E53D3A6909 for ; Sat, 19 Dec 2009 13:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ijjTCoeayTAN for ; Sat, 19 Dec 2009 13:43:19 -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 A264D3A685B for ; Sat, 19 Dec 2009 13:43:19 -0800 (PST) Received: by pwi20 with SMTP id 20so2779667pwi.29 for ; Sat, 19 Dec 2009 13:43:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.85.16 with SMTP id n16mr3145978wal.123.1261258980072; Sat, 19 Dec 2009 13:43:00 -0800 (PST) In-Reply-To: <4B2D22C6.9090109@extendedsubset.com> References: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> <4B2D22C6.9090109@extendedsubset.com> Date: Sat, 19 Dec 2009 13:43:00 -0800 Message-ID: <3561bdcc0912191343n33b51ebdh260d8048ecd0857f@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e64ca2a67a1dd9047b1bbdac Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 21:43:21 -0000 --0016e64ca2a67a1dd9047b1bbdac Content-Type: text/plain; charset=UTF-8 Comments: i) The term "abbreviated handshake" (which appears only in the title of figure of said handshake on Pg. 32 of RFC 5246, and in numerous references on the web. It seems to be used synonymously with 'session resumption' (which appears many more times in the same RFC). I prefer abbreviated, as one can open a million parallel connections with a master_secret that is once exchanged, which the term 'resumption' does not quite convey. ii) You say: "Why couldn't a client offer resumption of a previously client-authed session in response to a server-initiated renegotiation?". In re-reading RFC 5246 my take away is that this is implicitly forbidden, but maybe that is just my reading. I feel it really MUST be forbidden. As an example: - imagine an application requirement to change key material every 24 hours, because after that an attacker gathers up enough ciphertext or chosen plaintext to render continuing to use the same key material dangerous. - app developer instructs his (server) SSL stack to do 'renegotiation' every 24 hours. - applications (server) SSl stack sends renegottation message'. - In your scenario (client) stack at other end says "oh come on, not all over again, lets just resume" and commences abbreviated handshake using same master_secret. - In your scenario the (server) SSL stack proceeds, and the app "thinks" it is refreshing key material every 24 hours, and in fact it is not!!! My recommendation would be to say a Client MUST NOT offer session resumption in response to a renegotiation, and if it chooses to do so, the server MUST NOT accept it. It would be useful if any of those originally involved with RFC 5246 can clarify intent of renegotiation and if any why there is indeed some use case where one allows Client to respond with abbreviated handshake. Like Marsh, I cannot think of any use case, and per my example above it seems dangerous. If one agrees the draft to fix the renego-attack would be great place to fix this too. iii) OK back to abbreviated handshakes. As part of my work with the MashSSL Alliance (www.mashssl.org) I end up explaining the abbreviated handshake again and again and again, as it is a HUGE benefit of starting with SSL to fix the problem we are trying to address. Here is what I have to report: Of those who know enough about SSL to ask, *ALL* immediately confuse it with "renegotiation" and ask about the impact of your attack (currently MashSSL does not even have renegotiation!). Now your draft has no obligation to change its wording to help a different if related effort (though it would be nice :-)). I am simply reporting back that almost everyone is mixed up on 'resumption' versus 'renegotiation'. And it would help a lot of people if your reply to me below, namely, "The bug and the fix are about renegotiation and have absolutely nothing to do with session resumption." made it into the draft. iv) Finally, your choice of words on 'binding' captures what I was trying to say; I just said it poorly. Cheers, Ravi -- Ravi Ganesan ravi@findravi.com www.findravi.com On Sat, Dec 19, 2009 at 11:00 AM, Marsh Ray wrote: > Ravi Ganesan wrote: > > > > Well, it also applies to a renegotiated abbreviated handshake (where > a > > renegotiating handshake resumes an existing session). The spec should > > probably point out that this case is possible, and that exactly the > same > > attacks and defences apply. > > > > David-Sarah Hopwood ? http://davidsarah.livejournal.com > > > > > > This may be my ignorance, but I assumed the purpose of renegotiation > > was a fresh exchange of authentication and/or keying material. > > Forget 'purpose', that's largely an application layer thing. > > The TLS spec defines mechanisms: what MAY, SHOULD, and MUST happen. > > Whether it's freshening keys, changing auth, etc. what others do with a > basic feature like renegotiation is up to them. > > > The > > renego for instance can (infamously) require client-auth while the > > original did not. Or switch ciphersuites. > > My belief is that that was one of the original intended purposes for > renegotiation: allow Netscape clients and servers to handle > per-directory client certificate and crypto configuration. > > > The abbreviated handshake cannot achieve any of this. It does not > > involve certs or ciphersuites. > > Sure, why not? Why couldn't a client offer resumption of a previously > client-authed session in response to a server-initiated renegotiation? > > > I thought historically its purpose > > versus: the full handshake exchanges the master-secret in the context of > > a particular TCP-socket. > > No, that's the mechanism. > > > If the Client wants to use that same master > > secret in the context of a new ( or a million parallel) TCP sockets, > > then use the abbreviated handshake (avoiding the PKI heavy lifting). > > Saving computation is probably the most common use of session resumption. > > > The > > same thing applies if the binding underneath is not TCP. The > > abbreviated handshake really has only one purpose in life -- it binds > > the new SSL session (say the new TCP socket) to the old one, > > Sort of. If the resumption is successful, it ends up being just one > session which is instantiated on multiple connections. > > I haven't heard anyone thinking of it so much in terms of "binding" two > TCP connections. Since you can't usually guarantee that session > resumption will be successful, application protocols usually don't give > it any semantic meaning. > > > by each > > party proving knowledge of the original master secret. (exactly what the > > renegotiated handshake chose not to do). > > A renegotiation handshake can resume a session if client and server > agree on it. > > > Examples would be a messengering client that negotiates a full > > handshake with a switch and then each time a new socket is opened for a > > new message uses the abbreviated handshake. Or a page with many many SSL > > protected objects that are independently retrieved. So in this context > > a "renegotiated abbreviated handshake" seems strange. > > It's not clear what the use case is for doing session resumption on a > renegotiation. > > But it really just falls naturally out of the basic design of TLS. The > spec doesn't have to call it out as a special case. > > > But regardless even if there is something in existence called a > > "renegotiated abbreviated handshake", I think the distinction between > > 'abbreviated handshakes without renegoitation' which are very very > > widely used should not be confused with 'renegotiated handshakes of any > > kind'. > > Nowhere in the draft does it talk about "abbreviated handshakes". > Whether or not a handshake is "abbreviated" has absolutely nothing to do > with whether or not it is an initial or a renegotiation handshake. > > You could just as easily single out some other protocol feature, say > Diffie-Hellman key exchange, and say there's an under-appreciated > distinction between initial DH handshakes and every other kind of > handshake. > > > It would be very helpful if the draft made this point. > > The bug and the fix are about renegotiation and have absolutely nothing > to do with session resumption. Nevertheless, we already reiterate this > point a couple of times in the draft. > > http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt: > > "The above rules apply even when TLS session resumption is used." > > "... with every ClientHello, including ClientHellos where session > resumption is being offered." > > - Marsh > > --0016e64ca2a67a1dd9047b1bbdac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Comments:

i) The term "abbreviated handshake"=C2=A0 (which= appears only in the title of figure of said handshake on Pg. 32 of RFC 524= 6, and in numerous references on the web.=C2=A0 It seems to be used synonym= ously with=C2=A0 'session resumption'=C2=A0 (which appears many mor= e times in the same RFC). I prefer abbreviated, as one can open a million p= arallel connections with a master_secret that is once exchanged, which the = term 'resumption' does not quite convey.

ii) You say: "Why couldn't a client offer resumption of a prev= iously=C2=A0 client-authed session in response to a server-initiated renegotiation?"= ;. In re-reading RFC 5246 my take away is that this is implicitly forbidden= , but maybe that is just my reading. I feel it really MUST be forbidden.=C2= =A0 As an example:
-=C2=A0 imagine an application requirement to change key material every 24 = hours, because after that an attacker gathers up enough ciphertext or chose= n plaintext to render continuing to use the same key material dangerous. - app developer instructs his (server) SSL stack to do 'renegotiation&#= 39; every 24 hours.
- applications (server) SSl stack sends renegottatio= n message'.
- In your scenario (client) stack at other end says &quo= t;oh come on, not all over again, lets just resume" and commences abbr= eviated handshake using same master_secret.
- In your scenario the (server) SSL stack proceeds, and the app "think= s" it is refreshing key material every 24 hours, and in fact it is not= !!!
My recommendation would be to say a Client MUST NOT offer session re= sumption in response to a renegotiation, and if it chooses to do so, the se= rver MUST NOT accept it.=C2=A0 It would be useful if any of those originall= y involved with RFC 5246 can clarify intent of renegotiation and if any why= there is indeed some use case where one allows Client to respond with abbr= eviated handshake. Like Marsh, I cannot think of any use case, and per my e= xample above it seems dangerous. If one agrees the draft to fix the renego-= attack would be great place to fix this too.

iii) OK back to abbreviated handshakes. As part of my work with the Mas= hSSL Alliance (www.mashssl.org) I en= d up explaining the abbreviated handshake again and again and again, as it = is a HUGE benefit of starting with SSL to fix the problem we are trying to = address. Here is what I have to report: Of those who know enough about SSL = to ask, *ALL* immediately confuse it with "renegotiation" and ask= about the impact of your attack (currently MashSSL does not even have rene= gotiation!).=C2=A0 Now your draft has no obligation to change its wording t= o help a different if related effort (though it would be nice :-)). I am si= mply reporting back that almost everyone is mixed up on=C2=A0 'resumpti= on' versus 'renegotiation'. And it would help a lot of people i= f your reply to me=C2=A0 below, namely, "The bug and the fix are about= renegotiation and have absolutely nothing to do with session resumption." made it into the draft.

iv) Fi= nally, your choice of words on 'binding' captures what I was trying= to say; I just said it poorly.

Cheers,

Ravi

--
Ravi Ganesan
ravi@findravi.com<= br>www.findravi.com


On Sat, Dec 19, 2009 at 11:00 AM, Marsh Ray <marsh@extendedsub= set.com> wrote:
Ravi Ganesan wrote:
>
> =C2=A0 =C2=A0 Well, it also applies to a renegotiated abbreviated hand= shake (where a
> =C2=A0 =C2=A0 renegotiating handshake resumes an existing session). Th= e spec should
> =C2=A0 =C2=A0 probably point out that this case is possible, and that = exactly the same
> =C2=A0 =C2=A0 attacks and defences apply.
>
> =C2=A0 =C2=A0 David-Sarah Hopwood =C2=A0? =C2=A0http://davidsarah.livejournal.com=
>
>
> This may be =C2=A0my ignorance, but I assumed the purpose of renegotia= tion
> was a fresh exchange of authentication and/or keying material.

Forget 'purpose', that's largely an app= lication layer thing.

The TLS spec defines mechanisms: what MAY, SHOULD, and MUST happen.

Whether it's freshening keys, changing auth, etc. what others do with a=
basic feature like renegotiation is up to them.

> The
> renego for instance can (infamously) require client-auth while the
> original did not. Or switch ciphersuites.

My belief is that that was one of the original inte= nded purposes for
renegotiation: allow Netscape clients and servers to handle
per-directory client certificate and crypto configuration.

> The abbreviated handshake cannot achieve any o= f this. It does not
> involve certs or ciphersuites.

Sure, why not? Why couldn't a client offer resu= mption of a previously
client-authed session in response to a server-initiated renegotiation?

> I thought historically its purpose
> versus: the full handshake exchanges the master-secret in the context = of
> a particular TCP-socket.

No, that's the mechanism.

> If the Client wants to use that same master > secret in the context of a new ( or a million parallel) TCP sockets, > then use the abbreviated handshake (avoiding the PKI heavy lifting).
Saving computation is probably the most common use = of session resumption.

> The
> same thing applies if the binding underneath is not TCP. =C2=A0The
> abbreviated handshake really has only one purpose in life -- it binds<= br> > the new SSL session (say the new TCP socket) to the old one,

Sort of. If the resumption is successful, it ends u= p being just one
session which is instantiated on multiple connections.

I haven't heard anyone thinking of it so much in terms of "binding= " two
TCP connections. Since you can't usually guarantee that session
resumption will be successful, application protocols usually don't give=
it any semantic meaning.

> by each
> party proving knowledge of the original master secret. (exactly what t= he
> renegotiated handshake chose not to do).

A renegotiation handshake can resume a session if c= lient and server
agree on it.

> Examples =C2=A0would =C2=A0be a messengering c= lient that negotiates a full
> handshake with a switch and then each time a new socket is opened for = a
> new message uses the abbreviated handshake. Or a page with many many S= SL
> protected objects that are independently retrieved. =C2=A0So in this c= ontext
> a "renegotiated abbreviated handshake" seems strange.

It's not clear what the use case is for doing s= ession resumption on a
renegotiation.

But it really just falls naturally out of the basic design of TLS. The
spec doesn't have to call it out as a special case.

> But regardless even if there is something in e= xistence called a
> "renegotiated abbreviated handshake", I think the distinctio= n between
> 'abbreviated handshakes without renegoitation' which are very = very
> widely used should not be confused with 'renegotiated handshakes o= f any
> kind'.

Nowhere in the draft does it talk about "abbre= viated handshakes".
Whether or not a handshake is "abbreviated" has absolutely nothin= g to do
with whether or not it is an initial or a renegotiation handshake.

You could just as easily single out some other protocol feature, say
Diffie-Hellman key exchange, and say there's an under-appreciated
distinction between initial DH handshakes and every other kind of handshake= .

> It would be very helpful if the draft made thi= s point.

The bug and the fix are about reneg= otiation and have absolutely nothing
to do with session resumption. Nevertheless, we already reiterate this
point a couple of times in the draft.

http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt:

"The above rules apply even when TLS session resumption is used."=

"... with every ClientHello, including ClientHellos where session
resumption is being offered."

- Marsh




--0016e64ca2a67a1dd9047b1bbdac-- From mike-list@pobox.com Sat Dec 19 14:12: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 408463A684C for ; Sat, 19 Dec 2009 14:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 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 GD-OIb1u6dtB for ; Sat, 19 Dec 2009 14:12: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 B5B043A67EC for ; Sat, 19 Dec 2009 14:12:44 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7A191A8812 for ; Sat, 19 Dec 2009 17:12: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=e6lyp5vyQ5ML vZTQf6hXhDdS0c4=; b=tTzsC5Msj3qnttNEGXwPfl8uoLxmSCuHnADHn5ObIb6E O22lNgVZobA98lcDqMPAfMjP47PCASxHOlU9C1QeUVlRyatUkIQD0U7adKGaZ7hA Hnw/9JwiRzs9uKi0D7lXUrhUkCMYJDwysp5jDXPdw37jtMrBId2bW092oLp5s08= 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=us9uWE +ICThAY+vHpUZ77oe3GvXuTDXPZZn7B1AWrUA7yp24jsOc2uE9B8JqC7hcCA6Gf9 Pt7Jz7uCE2R6PUeqpDNq5VK9t+4ijbQtzivhur8C1etcrq6I0yRRAlQry0CP/nW6 shyC74KFUR48qtRLljD3q+dC0KPEHTfho3HZg= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 769FAA8810 for ; Sat, 19 Dec 2009 17:12: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 073FBA880F for ; Sat, 19 Dec 2009 17:12:27 -0500 (EST) Message-ID: <4B2D503F.2060800@pobox.com> Date: Sat, 19 Dec 2009 14:14:23 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> <4B2D22C6.9090109@extendedsubset.com> <3561bdcc0912191343n33b51ebdh260d8048ecd0857f@mail.gmail.com> In-Reply-To: <3561bdcc0912191343n33b51ebdh260d8048ecd0857f@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 984EDF9E-ECEB-11DE-91DD-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 22:12:47 -0000 Ravi Ganesan wrote: > > ii) You say: "Why couldn't a client offer resumption of a previously > client-authed session in response to a server-initiated renegotiation?". > In re-reading RFC 5246 my take away is that this is implicitly > forbidden, but maybe that is just my reading. I feel it really MUST be > forbidden. As an example: > - imagine an application requirement to change key material every 24 > hours, because after that an attacker gathers up enough ciphertext or > chosen plaintext to render continuing to use the same key material > dangerous. > - app developer instructs his (server) SSL stack to do 'renegotiation' > every 24 hours. > - applications (server) SSl stack sends renegottation message'. > - In your scenario (client) stack at other end says "oh come on, not all > over again, lets just resume" and commences abbreviated handshake using > same master_secret. > - In your scenario the (server) SSL stack proceeds, and the app "thinks" > it is refreshing key material every 24 hours, and in fact it is not!!! The server is under no obligation to resume a session offered by the client. If your server application requires a full handshake every 24 hours, then it should ignore the session ID and simply continue with a full handshake. > My recommendation would be to say a Client MUST NOT offer session > resumption in response to a renegotiation, and if it chooses to do so, > the server MUST NOT accept it. It would be useful if any of those > originally involved with RFC 5246 can clarify intent of renegotiation > and if any why there is indeed some use case where one allows Client to > respond with abbreviated handshake. Like Marsh, I cannot think of any > use case, and per my example above it seems dangerous. If one agrees the > draft to fix the renego-attack would be great place to fix this too. I don't think these restrictions are necessary. It is up to the particular application to determine when resumption is allowed and when it isn't. The client can force a full handshake by not sending a session ID, and the server can force a full handshake by ignoring a session ID if the client sent one. > iii) OK back to abbreviated handshakes. As part of my work with the > MashSSL Alliance (www.mashssl.org ) I end up > explaining the abbreviated handshake again and again and again, as it is > a HUGE benefit of starting with SSL to fix the problem we are trying to > address. Here is what I have to report: Of those who know enough about > SSL to ask, *ALL* immediately confuse it with "renegotiation" and ask > about the impact of your attack (currently MashSSL does not even have > renegotiation!). Now your draft has no obligation to change its wording > to help a different if related effort (though it would be nice :-)). I > am simply reporting back that almost everyone is mixed up on > 'resumption' versus 'renegotiation'. And it would help a lot of people > if your reply to me below, namely, "The bug and the fix are about > renegotiation and have absolutely nothing to do with session > resumption." made it into the draft. Renegotiation and session resumption are orthogonal. You can resume a session on an initial handshake or when renegotiating. I'm not sure your text is quite correct since you can be vulnerable to a man-in-the- middle when resuming a session on an initial handshake (the server sees it as a renegotiation). Mike From ekr@networkresonance.com Sat Dec 19 14:13: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 B82C43A684C for ; Sat, 19 Dec 2009 14:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 rtVS4sVsApdI for ; Sat, 19 Dec 2009 14:13:54 -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 2CCB33A62C1 for ; Sat, 19 Dec 2009 14:13:54 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 46E066C89B6; Sat, 19 Dec 2009 14:14:16 -0800 (PST) Date: Sat, 19 Dec 2009 14:14:15 -0800 From: Eric Rescorla To: Ravi Ganesan In-Reply-To: <3561bdcc0912191343n33b51ebdh260d8048ecd0857f@mail.gmail.com> References: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> <4B2D22C6.9090109@extendedsubset.com> <3561bdcc0912191343n33b51ebdh260d8048ecd0857f@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: <20091219221416.46E066C89B6@kilo.networkresonance.com> Cc: tls@ietf.org Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 22:13:59 -0000 At Sat, 19 Dec 2009 13:43:00 -0800, > ii) You say: "Why couldn't a client offer resumption of a previously > client-authed session in response to a server-initiated renegotiation?". In > re-reading RFC 5246 my take away is that this is implicitly forbidden, but > maybe that is just my reading. I don't see any text in 5246 that seems to forbid this. > - imagine an application requirement to change key material every 24 hours, > because after that an attacker gathers up enough ciphertext or chosen > plaintext to render continuing to use the same key material dangerous. IMO, this is a bogus requirement: 1. Modern ciphers do not suffer from key exhaustion. You should be able to use the same key for effectively any plausible amount of ciphertext. 2. To the exten to which you *are* worried about key exhaustion (or something like CBC rollover), then merely re-deriving the keys from the original master secret is quite sufficient. There is no need to do a new public key exchange. > - app developer instructs his (server) SSL stack to do 'renegotiation' every > 24 hours. > - applications (server) SSl stack sends renegottation message'. > - In your scenario (client) stack at other end says "oh come on, not all > over again, lets just resume" and commences abbreviated handshake using same > master_secret. > - In your scenario the (server) SSL stack proceeds, and the app "thinks" it > is refreshing key material every 24 hours, and in fact it is not!!! Either side has the option to decide to do a full handshake. If they want that, then either the client should not offer resumption or the server should not accept it. It's not clear to me why such a restriction would need to be in TLS proper. -Ekr From ravi@findravi.com Sat Dec 19 15:07: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 75C7D3A6996 for ; Sat, 19 Dec 2009 15:07:45 -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.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 M2t9ILfQzCIU for ; Sat, 19 Dec 2009 15:07:44 -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 6D13C3A6911 for ; Sat, 19 Dec 2009 15:07:44 -0800 (PST) Received: by pwi20 with SMTP id 20so2797369pwi.29 for ; Sat, 19 Dec 2009 15:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.86.5 with SMTP id j5mr3695042wab.0.1261264046813; Sat, 19 Dec 2009 15:07:26 -0800 (PST) In-Reply-To: <20091219221416.46E066C89B6@kilo.networkresonance.com> References: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> <4B2D22C6.9090109@extendedsubset.com> <3561bdcc0912191343n33b51ebdh260d8048ecd0857f@mail.gmail.com> <20091219221416.46E066C89B6@kilo.networkresonance.com> Date: Sat, 19 Dec 2009 15:07:26 -0800 Message-ID: <3561bdcc0912191507y45ec359bma3b32f12dbcad07@mail.gmail.com> From: Ravi Ganesan To: Eric Rescorla Content-Type: multipart/alternative; boundary=00504502e13b7a7277047b1ceb15 Cc: tls@ietf.org Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 23:07:45 -0000 --00504502e13b7a7277047b1ceb15 Content-Type: text/plain; charset=UTF-8 I agree completely with the comments below, and those of Mike, that a smart app completely aware of the doings of the ssl stack, can ensure the ssl stack underneath it does not do something unexpected. One could by the same token claim that a smart app aware of the doings of the ssl stack would not have mixed up the before and after of the 'pizza order' in your exposition of the original attack. I figured the goals were to save a not-so-smart app from itself to extent possible. Anyway, for my taste, if one side says I want to renegotiate, and the other responds with a message that results in NON-renegotiation it makes no sense to allow it within TLS itself. I have not seen any use case where this peculiar behaviour should be tolerated. And if such a use case does not exist, it might be wise to be parsimonious and disallow it. On Sat, Dec 19, 2009 at 2:14 PM, Eric Rescorla wrote: > At Sat, 19 Dec 2009 13:43:00 -0800, > > ii) You say: "Why couldn't a client offer resumption of a previously > > client-authed session in response to a server-initiated renegotiation?". > In > > re-reading RFC 5246 my take away is that this is implicitly forbidden, > but > > maybe that is just my reading. > > I don't see any text in 5246 that seems to forbid this. > > > > - imagine an application requirement to change key material every 24 > hours, > > because after that an attacker gathers up enough ciphertext or chosen > > plaintext to render continuing to use the same key material dangerous. > > IMO, this is a bogus requirement: > > 1. Modern ciphers do not suffer from key exhaustion. You should be able > to use the same key for effectively any plausible amount of ciphertext. > 2. To the exten to which you *are* worried about key exhaustion (or > something like CBC rollover), then merely re-deriving the keys from > the original master secret is quite sufficient. There is no need > to do a new public key exchange. > > > > - app developer instructs his (server) SSL stack to do 'renegotiation' > every > > 24 hours. > > - applications (server) SSl stack sends renegottation message'. > > - In your scenario (client) stack at other end says "oh come on, not all > > over again, lets just resume" and commences abbreviated handshake using > same > > master_secret. > > - In your scenario the (server) SSL stack proceeds, and the app "thinks" > it > > is refreshing key material every 24 hours, and in fact it is not!!! > > Either side has the option to decide to do a full handshake. If they > want that, then either the client should not offer resumption or the > server should not accept it. It's not clear to me why such a restriction > would need to be in TLS proper. > > -Ekr > > > -- Ravi Ganesan ravi@findravi.com www.findravi.com --00504502e13b7a7277047b1ceb15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree completely with the comments below, and those of Mike, that a smart= app completely aware of the doings of the ssl stack, can ensure the ssl st= ack underneath it does not do something unexpected. One could by the same t= oken claim that a smart app aware of the doings of the ssl stack would not = have mixed up the before and after of the 'pizza order' in your exp= osition of the original attack. I figured the goals were to save a not-so-s= mart app from itself to extent possible.

Anyway, for my taste, if one side says I want to renegotiate, and the o= ther responds with a message that results in NON-renegotiation it makes no = sense to allow it within TLS itself.=C2=A0 I have not seen any use case whe= re this peculiar behaviour should be tolerated. And if such a use case does= not exist, it might be wise to be parsimonious and disallow it.




On Sat, Dec 19, 2009 at 2:14 PM,= Eric Rescorla <ekr@networkresonance.com> wrote:
At Sat, 19 Dec 2009 13:43:00 -0800,
> ii) You say: "Why couldn't a client o= ffer resumption of a previously
> client-authed session in response to a server-initiated renegotiation?= ". In
> re-reading RFC 5246 my take away is that this is implicitly forbidden,= but
> maybe that is just my reading.

I don't see any text in 5246 that seems to forb= id this.


> - =C2=A0imagine an application requirement to change key materia= l every 24 hours,
> because after that an attacker gathers up enough cip= hertext or chosen
> plaintext to render continuing to use the same key material dangerous.=

IMO, this is a bogus requirement:

1. Modern ciphers do not suffer from key exhaustion. You should be able
=C2=A0 to use the same key for effectively any plausible amount of ciphert= ext.
2. To the exten to which you *are* worried about key exhaustion (or
=C2=A0 something like CBC rollover), then merely re-deriving the keys from=
=C2=A0 the original master secret is quite sufficient. There is no need =C2=A0 to do a new public key exchange.


> - app developer instructs his (server) SSL sta= ck to do 'renegotiation' every
> 24 hours.
> - applications (server) SSl stack sends renegottation message'. > - In your scenario (client) stack at other end says "oh come on, = not all
> over again, lets just resume" and commences abbreviated handshake= using same
> master_secret.
> - In your scenario the (server) SSL stack proceeds, and the app "= thinks" it
> is refreshing key material every 24 hours, and in fact it is not!!!
Either side has the option to decid= e to do a full handshake. If they
want that, then either the client should not offer resumption or the
server should not accept it. It's not clear to me why such a restrictio= n
would need to be in TLS proper.

-Ekr





--
Ravi Ganesa= n
ravi@findravi.com
www.findravi.com
--00504502e13b7a7277047b1ceb15-- From s@pahtak.org Sat Dec 19 15:20: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 CB0CA3A69F8 for ; Sat, 19 Dec 2009 15:20:45 -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.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJBpzsDRyC2i for ; Sat, 19 Dec 2009 15:20: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 17B853A6980 for ; Sat, 19 Dec 2009 15:20:45 -0800 (PST) Received: by pwi20 with SMTP id 20so2800198pwi.29 for ; Sat, 19 Dec 2009 15:20:27 -0800 (PST) Received: by 10.142.7.18 with SMTP id 18mr3561294wfg.126.1261264827357; Sat, 19 Dec 2009 15:20:27 -0800 (PST) Received: from mb.pahtak.org (ip68-107-82-55.sd.sd.cox.net [68.107.82.55]) by mx.google.com with ESMTPS id 20sm3714740pzk.5.2009.12.19.15.20.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 19 Dec 2009 15:20:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Checkoway In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE85400B@LLE2K7-BE01.mitll.ad.local> Date: Sat, 19 Dec 2009 15:20:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1312AA6E-DA71-444A-B6B4-2E8218F0035B@pahtak.org> References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE85400B@LLE2K7-BE01.mitll.ad.local> To: tls@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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: Sat, 19 Dec 2009 23:20:46 -0000 On Dec 19, 2009, at 5:24 AM, Blumenthal, Uri - 0662 - MITLL wrote: > You're saying it's not important whether the protocol spec demands = aborting the connection or not?! =20 As long as the spec is clear about what to do in that case (either abort = or not), it doesn't really matter what the decision is. The code is = about the same. The amount of testing is identical as far as I can tell. > As long as the processing amount to arrive at the decision is about = the same? I don't know what this means. --=20 Steve Checkoway From mike-list@pobox.com Sat Dec 19 15:32: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 1A07C3A6989 for ; Sat, 19 Dec 2009 15:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRgUsadAeZNa for ; Sat, 19 Dec 2009 15:32: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 1E09D3A6980 for ; Sat, 19 Dec 2009 15:32:13 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3C4838939A for ; Sat, 19 Dec 2009 18:31: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=AcVB8LD6iS9k kBI+YQeV6oqvOWM=; b=bPwhRekcviE0NvTtcO7a5pQ3KRlhsLj2ZfqdrMbvvVmv r7Md4QXr3/g3DRUNCkyohIStHFa1VaVLDWkUsufWfH8sgl2JnsaJR/HJGyH6xNwC Lt9H1v0ZWNxbKlx5dvUDCTQHI4YnfOej7cpHM0Jhr49hQwUOZZ7Z5ZMBExo0lRw= 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=apFvMr gTTEvA1X6scC7AUi3u0xIzwzOHWU+VYwpCiLQ0AV7fEyoIEdsvD52DdHIS73guGj njY8CzVWwbdgoScnerCZmf//20Y2rvqiuOnhZXO/zk6ZkUTKQP/Brn9uOS2m49N7 iXLz4bXl4IC8P3+FEyU3WQDo7Pl+UXdOj4fZ4= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3A2C289399 for ; Sat, 19 Dec 2009 18:31: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 D122A89398 for ; Sat, 19 Dec 2009 18:31:56 -0500 (EST) Message-ID: <4B2D62E0.2090509@pobox.com> Date: Sat, 19 Dec 2009 15:33:52 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> <4B2D22C6.9090109@extendedsubset.com> <3561bdcc0912191343n33b51ebdh260d8048ecd0857f@mail.gmail.com> <20091219221416.46E066C89B6@kilo.networkresonance.com> <3561bdcc0912191507y45ec359bma3b32f12dbcad07@mail.gmail.com> In-Reply-To: <3561bdcc0912191507y45ec359bma3b32f12dbcad07@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: B2B5D8E6-ECF6-11DE-9D78-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2009 23:32:14 -0000 Ravi Ganesan wrote: > I agree completely with the comments below, and those of Mike, that a > smart app completely aware of the doings of the ssl stack, can ensure > the ssl stack underneath it does not do something unexpected. One could > by the same token claim that a smart app aware of the doings of the ssl > stack would not have mixed up the before and after of the 'pizza order' > in your exposition of the original attack. I figured the goals were to > save a not-so-smart app from itself to extent possible. Preventing session resumption is (or should be) easy for the server. Just set a maximum session lifetime in your session cache. If the client attempts to resume a session older than that, the server won't find it in the cache and will be forced into a full handshake. > Anyway, for my taste, if one side says I want to renegotiate, and the > other responds with a message that results in NON-renegotiation it makes > no sense to allow it within TLS itself. I have not seen any use case > where this peculiar behaviour should be tolerated. And if such a use > case does not exist, it might be wise to be parsimonious and disallow it. You've confused renegotiation with resumption. The peers DO renegotiate, but they perform a full handshake if either side doesn't want to resume a previous session. Mike From mrex@sap.com Sat Dec 19 15:35: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 CD9263A68F9 for ; Sat, 19 Dec 2009 15:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 Q1TvWRFO7rc8 for ; Sat, 19 Dec 2009 15:35:01 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id B452B3A68C2 for ; Sat, 19 Dec 2009 15:35:00 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBJNYgm8016156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Dec 2009 00:34:42 +0100 (MET) From: Martin Rex Message-Id: <200912192334.nBJNYfU0011268@fs4113.wdf.sap.corp> To: ravi@findravi.com (Ravi Ganesan) Date: Sun, 20 Dec 2009 00:34:41 +0100 (MET) In-Reply-To: <3561bdcc0912191507y45ec359bma3b32f12dbcad07@mail.gmail.com> from "Ravi Ganesan" at Dec 19, 9 03:07: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: tls@ietf.org Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake 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, 19 Dec 2009 23:35:07 -0000 Ravi Ganesan wrote: > > I agree completely with the comments below, and those of Mike, that a smart > app completely aware of the doings of the ssl stack, can ensure the ssl > stack underneath it does not do something unexpected. One could by the same > token claim that a smart app aware of the doings of the ssl stack would not > have mixed up the before and after of the 'pizza order' in your exposition > of the original attack. I figured the goals were to save a not-so-smart app > from itself to extent possible. > > Anyway, for my taste, if one side says I want to renegotiate, and the other > responds with a message that results in NON-renegotiation it makes no sense > to allow it within TLS itself. I have not seen any use case where this > peculiar behaviour should be tolerated. And if such a use case does not > exist, it might be wise to be parsimonious and disallow it. Both sides can prevent a TLS session resume from happening during renegotation, so there is absolutely no problem at the protocol level. If the client does not want to resume a previous session during renegotiation, then it sends an empty TLS session ID in ClientHello. If the server does not want to resume a previous session during renegotiation, then it simply ignores the TLS session ID proposed in the ClientHello and performs a full TLS handshake. The HelloRequest handshake message does not carry an indicators why a server requests renegotiation, so a client can only guess. The most commonly known usage in popular applications on the internet seems the request for a client certificate after having seen the clients request. As EKR already mentioned, with old ciphers (short blocksize), doing renegotiation only for rekeying would be most efficient through TLS session resume, because it does not have PKI overhead (and also no certificate path validation overhead), only new encryption and MAC keys for both directions are newly derived (existing master secret plus client.random and server.random) and the 64-bit sequence numbers are reset. -Martin From djhopwood@googlemail.com Sat Dec 19 16: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 0D2CC3A696B for ; Sat, 19 Dec 2009 16:29: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 Uc8DT43-m6C3 for ; Sat, 19 Dec 2009 16:29:39 -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 062D83A683B for ; Sat, 19 Dec 2009 16:29:38 -0800 (PST) Received: by ewy1 with SMTP id 1so4978315ewy.28 for ; Sat, 19 Dec 2009 16:29: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=xfe8Jo2nqmw47u8Cb7OvxsccTVaUUtL5k7Pa6ZdygRI=; b=Qqr4XTSQ31DNntZG4kNY3H9VoCaDzhubof61TpY76FVuJIOTVSlmYSD6OjUycxmqtV anFa2s9PZd8RgsrHv0lk+FXwQYiOzlwt7mj819wY7ut30Yf3HEYGgrLjvx2dvKJOhgxa cwhx7sgqzXnjDD8xo5a9DRAZm9Xm7fgLXUaIg= 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=IBqrkX8SY6zimZpr5vIYNzm/LILNfDbVYwygH/WTX58yVLP8nWmvLxRN1zdvQY4Wns wwtYnu0haekAkCDZGQDAMKyNCoYfjQXY4/NywADBZhHwFCOMbdpiRmE38F6+rj7AWmpn eyC6ZRkI7zTqwwBK807jrij+jxP67fPd3VeRg= Received: by 10.213.100.168 with SMTP id y40mr7813900ebn.28.1261268958698; Sat, 19 Dec 2009 16:29:18 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 28sm7944320eyg.4.2009.12.19.16.29.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 19 Dec 2009 16:29:17 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B2D6FDB.9070504@jacaranda.org> Date: Sun, 20 Dec 2009 00:29: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: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> In-Reply-To: <3561bdcc0912190913t7bf4ea3fkc3ec29117b268b96@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigA9B0F6407D28F2601F7C8B1A" Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Dec 2009 00:29:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA9B0F6407D28F2601F7C8B1A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ravi Ganesan wrote: > David-Sarah Hopwood wrote: >> Ravi Ganesan wrote: >> >>> I know everyone on this thread knows otherwise, but the way the terms= get >>> used, can easily result in confusion between "full handshake", >> "abbreviated >>> handshake" and "renegotiated full handshake". The attack only applie= s of >>> course to last category, and NOT to the abbreviated handshake. >> Well, it also applies to a renegotiated abbreviated handshake (where a= >> renegotiating handshake resumes an existing session). The spec should >> probably point out that this case is possible, and that exactly the sa= me >> attacks and defences apply. > > This may be my ignorance, but I assumed the purpose of renegotiation w= as a > fresh exchange of authentication and/or keying material. The renego for= > instance can (infamously) require client-auth while the original did no= t. Or > switch ciphersuites. >=20 > The abbreviated handshake cannot achieve any of this. Yes it can; a renegotiation with an abbreviated handshake using the same session ID as the previous handshake, has the effect of refreshing keys. > But regardless even if there is something in existence called a > "renegotiated abbreviated handshake", I think the distinction between > 'abbreviated handshakes without renegoitation' which are very very wide= ly > used should not be confused with 'renegotiated handshakes of any kind'.= >=20 > It would be very helpful if the draft made this point. As long as it does so in a way that doesn't add further confusion, yes. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enigA9B0F6407D28F2601F7C8B1A 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/ iF4EAREIAAYFAkstb9sACgkQWUc8YzyzqAfHYgD9EXXo+FEQgnKUqsTFCoUjpmcr jaAxfie4FnQWlFoJEsgBAKH1DL0UzTjtHqAm/akwnCNYyWyKBmQ3Soh06GJg94dT =tHwT -----END PGP SIGNATURE----- --------------enigA9B0F6407D28F2601F7C8B1A-- From ravi@findravi.com Sat Dec 19 16: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 B73C73A690E for ; Sat, 19 Dec 2009 16:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8+6g1lQpJ91E for ; Sat, 19 Dec 2009 16:57:08 -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 08E2E3A690A for ; Sat, 19 Dec 2009 16:57:07 -0800 (PST) Received: by pzk6 with SMTP id 6so3064547pzk.29 for ; Sat, 19 Dec 2009 16:56:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.237.37 with SMTP id k37mr3752431wah.31.1261270610269; Sat, 19 Dec 2009 16:56:50 -0800 (PST) In-Reply-To: <200912192334.nBJNYfU0011268@fs4113.wdf.sap.corp> References: <3561bdcc0912191507y45ec359bma3b32f12dbcad07@mail.gmail.com> <200912192334.nBJNYfU0011268@fs4113.wdf.sap.corp> Date: Sat, 19 Dec 2009 16:56:50 -0800 Message-ID: <3561bdcc0912191656y16ec84f3g21862a90eaf4ea28@mail.gmail.com> From: Ravi Ganesan To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e64b95b6b0d926047b1e7240 Cc: tls@ietf.org Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Dec 2009 00:57:08 -0000 --0016e64b95b6b0d926047b1e7240 Content-Type: text/plain; charset=UTF-8 > The HelloRequest handshake message does not carry an indicators > why a server requests renegotiation, so a client can only guess. > The most commonly known usage in popular applications on > the internet seems the request for a client certificate after > having seen the clients request. > Sure, and in this case if the Client responds with a Client Hello with the initial session ID then the server has to anyway respond with a full handshake server-hello (else it cannot get client-auth). My only point is that we are relying on app that requests a "renegotiate" of its underlying SSL stack to differentiate between two cases: (i) where the renegotiate with full handshake really happens and (ii) when a previous session is resumed. If there is no need for case (ii) it seemed to me to be better to not let this happen, and hope the app can tell the difference. Sounds like everyone else thinks this is fine -- so be it. Cheers, Ravi --0016e64b95b6b0d926047b1e7240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


The HelloRequest handshake message does not carry an indicators
why a server requests renegotiation, so a client can only guess.
The most commonly known usage in popular applications on
the internet seems the request for a client certificate after
having seen the clients request.

Sure, and in this= case if the Client responds with a Client Hello with the initial session I= D then the server has to anyway respond with a full handshake server-hello = (else it cannot get client-auth).

My only point is that we are relying on app that requests a= "renegotiate" of its underlying SSL stack to differentiate betwe= en two cases: (i) where the renegotiate with full handshake really happens = and (ii) when a previous session is resumed. If there is no need for case (= ii) it seemed to me to be better to not let this happen, and hope the app c= an tell the difference.

Sounds like everyone else thinks this is fine -- so be it.

Cheer= s,

Ravi
--0016e64b95b6b0d926047b1e7240-- From ravi@findravi.com Sat Dec 19 17:24: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 960833A692E for ; Sat, 19 Dec 2009 17:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FacxVmVHTewT for ; Sat, 19 Dec 2009 17:24:37 -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 B2DE73A690E for ; Sat, 19 Dec 2009 17:24:37 -0800 (PST) Received: by pwi20 with SMTP id 20so2826038pwi.29 for ; Sat, 19 Dec 2009 17:24:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.187.20 with SMTP id k20mr3677242waf.213.1261272258377; Sat, 19 Dec 2009 17:24:18 -0800 (PST) In-Reply-To: References: Date: Sat, 19 Dec 2009 17:24:18 -0800 Message-ID: <3561bdcc0912191724h4b6721c6x5f9145f7e1d8524c@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e64b1e04ecf9ad047b1ed491 Subject: Re: [TLS] TLS Digest, Vol 65, Issue 86 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Dec 2009 01:24:38 -0000 --0016e64b1e04ecf9ad047b1ed491 Content-Type: text/plain; charset=UTF-8 > You've confused renegotiation with resumption. The peers DO renegotiate, > but they perform a full handshake if either side doesn't want to resume > a previous session. That would be ironic since I was trying to iron out the confusion between them. But it is entirely possible as a definition of renegotiation did not jump out at me from the RFC. If its there (and I carefully searched through RFC 5246 again just now) and I missed it my apologies in advance. If by renegotiation one means "brand new keying material" then the abbreviated handshake does not achieve it, as there is no new master_secret. If your definition is new encryption/hashing keys based on the old master_secret and the new (sent in clear and available to opponent) client_random and server_random, then sure you can say the peers do renegotiate. I would not call this renegotiate as for me the primary reason I'd want to renegotiate for privacy concerns is to use fresh keys. i.e. I'll assume that for whatever reason the security of my master_secret over time deteriorates and would be nice to start over afresh. (the only other reason for renegotiation I have seen so far, the serverauth-renego-clientauth sequence use case does not apply as they need to do a full handshake anyway to achieve that). But like I said, its pretty clear that everyone else is comfortable with allowing the abbreviated handshake to play out after one side requests a renegotiation - so, so be it!!! I do hope my other point on the distinction below makes it into the draft. Thx. Ravi > But regardless even if there is something in existence called a > "renegotiated abbreviated handshake", I think the distinction between > 'abbreviated handshakes without renegoitation' which are very very widely > used should not be confused with 'renegotiated handshakes of any kind'. > > It would be very helpful if the draft made this point. As long as it does so in a way that doesn't add further confusion, yes. --0016e64b1e04ecf9ad047b1ed491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > You've confused renegotiation with resumption. =C2=A0The peers DO = renegotiate,
> but they perform a full handshake if either side doesn't want to r= esume
> a previous session.

That would be ironic since I was trying to = iron out the confusion between them. But it is entirely possible as a defin= ition of renegotiation did not jump out at me from the RFC. If its there (a= nd I carefully searched through RFC 5246 again just now) and I missed it my= apologies in advance.=C2=A0 If by renegotiation one means "brand new = keying material"=C2=A0 then the abbreviated handshake does not achieve= it, as there is no new master_secret. If your definition is new encryption= /hashing keys based on the old master_secret and the new (sent in clear and= available to opponent) client_random and server_random, then sure you can = say the peers do renegotiate. I would not call this renegotiate as for me t= he primary reason I'd want to renegotiate for privacy concerns is to us= e fresh keys. i.e. I'll assume that for whatever reason the security of= my master_secret over time deteriorates and would be nice to start over af= resh. (the only other=C2=A0 reason for renegotiation I have seen so far, th= e serverauth-renego-clientauth sequence use case does not apply as they nee= d to do a full handshake anyway to achieve that).

But like I said, its pretty clear that everyone else is comfortable wit= h allowing the abbreviated handshake to play out after one side requests a = renegotiation - so, so be it!!! I do hope my other point on the distinction= below makes it into the draft. Thx. Ravi

> But regardless even if there is something in existence called a > "renegotiated abbreviated handshake", I think the distinctio= n between
> 'abbreviated handshakes without renegoitation' which are very = very widely
> used should not be confused with 'renegotiated handshakes of any k= ind'.
>
> It would be very helpful if the draft made this point.

As long as it does so in a way that doesn't add further confusion, yes.=

=C2=A0



--0016e64b1e04ecf9ad047b1ed491-- From mike-list@pobox.com Sat Dec 19 18:47: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 12AC83A6984 for ; Sat, 19 Dec 2009 18:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WuEkdxZkiqq for ; Sat, 19 Dec 2009 18:47: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 28AE43A6801 for ; Sat, 19 Dec 2009 18:47:50 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 01155A853D for ; Sat, 19 Dec 2009 21:47: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=62pExSqg1gTV RNfTA8djJQ55VUU=; b=GoECFV65wJKf72/2l0/efdm17tal6pbUjZXwtJot1an9 OvBIyMDIc7C2k56yBUTlGESDyI2fhIlUYiP9A9Qxzvih5RRyKsjEtt1YJYIQbaBO Vx2k/fVVMVd0y9ZKeOI7OQrHUoaAl5KyIXH7oUZyr7wLRn/m11pu2BjxHP7bAhc= 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=riKg9o HLwofVISxHtUi0knjgNCIk9fdH2wIiYpRlmIdyHhxirU3Wxr9MWwQdnmuejAxkmv 9TubUsWv2ND3i/yZkY+32QuorAUgZec5csNLYUa9rUQDmY+ZnJN7he9gzpKj+0X4 4Rus8Ue1ssreieTDmPmY2sO7NKA+2+TZk9D8w= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id F241FA853C for ; Sat, 19 Dec 2009 21:47:34 -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 9D19CA853B for ; Sat, 19 Dec 2009 21:47:34 -0500 (EST) Message-ID: <4B2D90BA.9030003@pobox.com> Date: Sat, 19 Dec 2009 18:49:30 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <3561bdcc0912191724h4b6721c6x5f9145f7e1d8524c@mail.gmail.com> In-Reply-To: <3561bdcc0912191724h4b6721c6x5f9145f7e1d8524c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 06F3CCEA-ED12-11DE-AC1A-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLS Digest, Vol 65, Issue 86 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Dec 2009 02:47:53 -0000 Ravi Ganesan wrote: > .... If by renegotiation one means "brand new keying > material" then the abbreviated handshake does not achieve it, as there > is no new master_secret. A renegotiation is a _handshake_ that occurs after the initial handshake. First, you perform an initial handshake to establish a secure channel. Then if you ever perform a handshake over this previously-established secure channel, you are renegotiating. The initial handshake may be full or abbreviated, and the renegotiation may be full or abbreviated. TLS does not require the renegotiation handshake to be related in any way to the initial handshake (except now we are adding the Renegotiation_Info extension to prevent man-in-the- middle attacks). A full handshake creates a new master secret and an abbreviated handshake reuses one. All handshakes generate new keying material based on the master secret. Mike From uri@ll.mit.edu Sat Dec 19 20:32: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 39D593A681F for ; Sat, 19 Dec 2009 20:32:31 -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 Vd+s-VBkHty8 for ; Sat, 19 Dec 2009 20:32:30 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 519513A659A for ; Sat, 19 Dec 2009 20:32:30 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBK4WEkq029981 for ; Sat, 19 Dec 2009 23:32:14 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAyRayd6; Sat Dec 19 23:31:01 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Sat, 19 Dec 2009 23:31:01 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Sat, 19 Dec 2009 23:31:00 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqBAeIE9W8rGao2RSefyfZdP3j55QAK1nAf Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@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] SCSV vs RI when both specified. Was: Updated 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: Sun, 20 Dec 2009 04:32:31 -0000 VGhlIG9ubHkgcHVycG9zZSBvZiBhbnkgcHJvdG9jb2wgaXMgdG8gYWxsb3cgZW50aXRpZXMgdG8g Y29tbXVuaWNhdGUgKHVuZGVyIGEgZ2l2ZW4gc2V0IG9mIGNvbnN0cmFpbnRzKS4gVGh1cyBldmVy eSBlZmZvcnQgU0hPVUxEIGJlIGludmVzdGVkIHRvIHByb3ZpZGUgdGhpcyBjYXBhYmlsaXR5IHdo ZW5ldmVyIHBvc3NpYmxlLiBJZiB0aGUgcHJvdG9jb2wgc3BlYyBkZW1hbmRzIGFib3J0aW5nIGNv bm5lY3Rpb24sIGl0IGJldHRlciBoYXZlIGEgZGFtbiBnb29kIHJlYXNvbiB0byBkbyBzbyAtIGFu ZCBtb3JlIHN1YnN0YW50aXZlIHRoYW4gInNvbWUgU3RldmUgZGVjaWRlZCBpdCBkb2Vzbid0IHJl YWxseSBtYXR0ZXIgdG8gaGltIGlmIHRoZSBwZWVycyBjb25uZWN0IG9yIG5vdCIuDQoNClBlcnNv bmFsIGN1cmlvc2l0eSAtIHdoYXQga2luZCBvZiB3b3JrIGRvIHlvdSBkbz8gKEZlZWwgZnJlZSB0 byBhbnN3ZXIgaW4gYSBwcml2YXRlIGVtYWlsIG9yIHRvIGlnbm9yZSBhbHRvZ2V0aGVyLikNCg0K SSdtIHNob2NrZWQgdGhhdCBub2JvZHkgZWxzZSBzZWVtcyB0byBwaWNrIG9uIHRoaXMuIElzIGl0 IHRoYXQgbWlkLXdlZWtlbmQgdGhpbmcsIG9yIGFtIEkgdGhlIG9ubHkgb25lIHdobyBjYXJlcyB3 aGV0aGVyIHRoZSBwZWVyIHdvdWxkIGVzdGFibGlzaCBvciByZWZ1c2UgY29ubmVjdGlvbj8hDQoN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogdGxzLWJvdW5jZXNAaWV0Zi5v cmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KVG86IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYub3Jn Pg0KU2VudDogU2F0IERlYyAxOSAxODoyMDoyNSAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBTQ1NW IHZzIFJJIHdoZW4gYm90aCBzcGVjaWZpZWQuIFdhczogVXBkYXRlZCBkcmFmdA0KDQoNCk9uIERl YyAxOSwgMjAwOSwgYXQgNToyNCBBTSwgQmx1bWVudGhhbCwgVXJpIC0gMDY2MiAtIE1JVExMIHdy b3RlOg0KDQo+IFlvdSdyZSBzYXlpbmcgaXQncyBub3QgaW1wb3J0YW50IHdoZXRoZXIgdGhlIHBy b3RvY29sIHNwZWMgZGVtYW5kcyBhYm9ydGluZyB0aGUgY29ubmVjdGlvbiBvciBub3Q/ISAgDQoN CkFzIGxvbmcgYXMgdGhlIHNwZWMgaXMgY2xlYXIgYWJvdXQgd2hhdCB0byBkbyBpbiB0aGF0IGNh c2UgKGVpdGhlciBhYm9ydCBvciBub3QpLCBpdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXIgd2hhdCB0 aGUgZGVjaXNpb24gaXMuIFRoZSBjb2RlIGlzIGFib3V0IHRoZSBzYW1lLiBUaGUgYW1vdW50IG9m IHRlc3RpbmcgaXMgaWRlbnRpY2FsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLg0KDQo+IEFzIGxvbmcg YXMgdGhlIHByb2Nlc3NpbmcgYW1vdW50IHRvIGFycml2ZSBhdCB0aGUgZGVjaXNpb24gaXMgYWJv dXQgdGhlIHNhbWU/DQoNCkkgZG9uJ3Qga25vdyB3aGF0IHRoaXMgbWVhbnMuDQoNCg0KLS0gDQpT dGV2ZSBDaGVja293YXkNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== From s@pahtak.org Sun Dec 20 07:12: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 4AF4E3A6819 for ; Sun, 20 Dec 2009 07:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHPNS7RqrR1D for ; Sun, 20 Dec 2009 07:12:49 -0800 (PST) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 210923A688C for ; Sun, 20 Dec 2009 07:12:49 -0800 (PST) Received: by pxi9 with SMTP id 9so3196061pxi.32 for ; Sun, 20 Dec 2009 07:12:31 -0800 (PST) Received: by 10.114.2.29 with SMTP id 29mr3502403wab.48.1261321950976; Sun, 20 Dec 2009 07:12:30 -0800 (PST) Received: from lonely.pahtak.org (ip68-107-82-55.sd.sd.cox.net [68.107.82.55]) by mx.google.com with ESMTPS id 21sm4399157pzk.3.2009.12.20.07.12.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 20 Dec 2009 07:12:29 -0800 (PST) Received: from dualg5.pahtak.org (dualg5.pahtak.org [192.168.1.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by lonely.pahtak.org (Postfix) with ESMTPSA id 8AF8B5C26D; Sun, 20 Dec 2009 07:12:28 -0800 (PST) Message-Id: <4F7AF248-A0E4-4EBE-82BB-F243F35FD9C2@pahtak.org> From: Steve Checkoway To: TLS Mailing List In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local> Content-Type: multipart/signed; boundary=Apple-Mail-26--453093176; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 20 Dec 2009 07:12:28 -0800 References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local> X-Mailer: Apple Mail (2.936) Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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: Sun, 20 Dec 2009 15:12:50 -0000 --Apple-Mail-26--453093176 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 19, 2009, at 8:31 PM, Blumenthal, Uri - 0662 - MITLL wrote: > The only purpose of any protocol is to allow entities to communicate > (under a given set of constraints). Thus every effort SHOULD be > invested to provide this capability whenever possible. If the > protocol spec demands aborting connection, it better have a damn > good reason to do so - and more substantive than "some Steve decided > it doesn't really matter to him if the peers connect or not". My point was merely that publication and subsequent implementation of the fix is more important than worrying about the specifics of what happens when two signals are used (as long as it is clearly specified, of course). Others may feel differently. > I'm shocked that nobody else seems to pick on this. Is it that mid- > weekend thing, or am I the only one who cares whether the peer would > establish or refuse connection?! There seem to be roughly 20 emails in this thread and its predecessor "Updated draft" talking about this starting with . -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier --Apple-Mail-26--453093176 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGGTCCAtIw ggI7oAMCAQICECjZEESO561wLe6hSYyS4IQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDkyNTA2MTQwNVoXDTEwMDkyNTA2MTQw NVowPjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMc0Bw YWh0YWsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7p9cy3FSDC8pQp2wZJk szOqOD5o56n9IXludNRnvM1qxXy/axIE5oFiJvrOEB4fZhMiuP8HAM74NJqUGSTl3aNXBVgwVRbW i+COSpfmObxiK3UFA/T2sn6cPLpJEFjY5TvekVEKLNAi2k4iIUw8BreHWZ1xnGAUA6Z/UbQoHI6c Vl/Rcu1dWNWTwCyUNYwX09JMFu0B9RQ09ltiZhjDurUG9Zt2qSIy8G4ptEtlYqibL2ugs0wW/Hkf PQadgqlt5V52WOFtObn+dcJxvnZ2b8goUaFRHaALidyEARSUJoZRrj0rCKOIkLhH8oU5bfoJ1X5p BaW/w5rU5WqfrEIC2QIDAQABoykwJzAXBgNVHREEEDAOgQxzQHBhaHRhay5vcmcwDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQUFAAOBgQA5NBSpsqBLU41YA9IQ8Ojqz5K7MSyVo2q3Amv/pQlmyPxw tAWfAeujwxgeZ1hlfLDWotLOkUr1QJDY+ouRg1c7v0hwdOrr1WYF2as/7XY3i7sJE9WxNbBbm8rc u5/OMrbIwb+JH4fX/EhzAZtUJfNqkoUIg9zSW8kESEJP/Gr+oTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQKNkQRI7nrXAt7qFJjJLghDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMjAxNTEyMjhaMCMGCSqGSIb3 DQEJBDEWBBSCRMrTubYpKM3LTnVVFcz4YTkE+TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECjZEESO561wLe6hSYyS4IQwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC ECjZEESO561wLe6hSYyS4IQwDQYJKoZIhvcNAQEBBQAEggEAR87uHKoH2nCiidLiLVPbFyO0op6a XRhC5/4Rg645GhdEfFYb4JEGSXMfhGDBDMP8PMNnoHGCp/HdW36YIlxunwRi8w4xnOleFU7ZOLmi MDARjTZd0RK4j/KT7hWHwjvQH9OYNuNs5llVpl5BC1uA7SygXt8WBCjzCLxoATGPZeIA3QzWMho1 u3IIPQYXt8QzztbeAovm5Zz/sIAmXkjQyhV8tC9OU4y5wvPPGg9qx91rTJu9u1Zk7i/1cuWwD9to kNuWFTOPkU8I14pRZwoqgan8EEwMBj05VhD1NoCPQrAzZ0/yQpG5Fm0dP6bW480v+MEYC/Zzn1FI xwWxFdxtcQAAAAAAAA== --Apple-Mail-26--453093176-- From mrex@sap.com Sun Dec 20 14: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 0A0DE3A688F for ; Sun, 20 Dec 2009 14:40:08 -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 wx9MOwK1m3nE for ; Sun, 20 Dec 2009 14:40: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 AA5533A67DF for ; Sun, 20 Dec 2009 14:40:05 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBKMdmF6017899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Dec 2009 23:39:48 +0100 (MET) From: Martin Rex Message-Id: <200912202239.nBKMdlg8004444@fs4113.wdf.sap.corp> To: s@pahtak.org (Steve Checkoway) Date: Sun, 20 Dec 2009 23:39:47 +0100 (MET) In-Reply-To: <4F7AF248-A0E4-4EBE-82BB-F243F35FD9C2@pahtak.org> from "Steve Checkoway" at Dec 20, 9 07:12:28 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] SCSV vs RI when both specified. Was: Updated 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: Sun, 20 Dec 2009 22:40:08 -0000 Steve Checkoway wrote: > > My point was merely that publication and subsequent implementation of > the fix is more important than worrying about the specifics of what > happens when two signals are used (as long as it is clearly specified, > of course). Others may feel differently. http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1827 -Martin From uri@ll.mit.edu Sun Dec 20 16:56: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 AC69F3A68ED for ; Sun, 20 Dec 2009 16:56:31 -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 a978ijuzSALf for ; Sun, 20 Dec 2009 16:56:30 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id A92903A6857 for ; Sun, 20 Dec 2009 16:56:30 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBL0uDAA009061 for ; Sun, 20 Dec 2009 19:56:13 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAFYainq; Sun Dec 20 19:53:58 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Sun, 20 Dec 2009 19:53:57 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Sun, 20 Dec 2009 19:53:56 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqBxVzyjJ1EhMYoQwKb4uPMSg4flAAErZfd Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@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] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 00:56:31 -0000 T0suIEthcmxzcnVoZSBzZXJ2ZXIgdGltZS1vdXRzIG9uIG1lLCBzbyBubyBjaGFuY2UgdG8gZ2V0 IGVubGlnaHRlbmVkIGJ5IGNoZWNraW5nIHRoYXQgdGhyZWFkLiBQbGVhc2UgaW5kdWxnZSBtZTog dGhlIG9uZSBzaG9ydCBjb21wZWxsaW5nIHJlYXNvbiB3aHkgd2UgZG9uJ3Qgd2FudCB0byBzYXkg IndoZW4gdHdvIHNpZ25hbHMgYXJlIHByZXNlbnQgdXNlIHRoaXMgb25lIGFuZCBpZ25vcmUgdGhl IG90aGVyIiBpbnN0ZWFkIG9mICJ3aGVuIHR3byBzaWduYWxzIGFyZSBwcmVzZW50IC0gYWJvcnQg Y29ubmVjdGlvbiIgLSBpcy4uLj8NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpG cm9tOiB0bHMtYm91bmNlc0BpZXRmLm9yZyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogU3Rl dmUgQ2hlY2tvd2F5IDxzQHBhaHRhay5vcmc+DQpDYzogdGxzQGlldGYub3JnIDx0bHNAaWV0Zi5v cmc+DQpTZW50OiBTdW4gRGVjIDIwIDE3OjM5OjQ3IDIwMDkKU3ViamVjdDogUmU6IFtUTFNdIFND U1YgdnMgUkkgd2hlbiBib3RoIHNwZWNpZmllZC4gV2FzOiBVcGRhdGVkIGRyYWZ0DQoNClN0ZXZl IENoZWNrb3dheSB3cm90ZToNCj4gDQo+IE15IHBvaW50IHdhcyBtZXJlbHkgdGhhdCBwdWJsaWNh dGlvbiBhbmQgc3Vic2VxdWVudCBpbXBsZW1lbnRhdGlvbiBvZiAgDQo+IHRoZSBmaXggaXMgbW9y ZSBpbXBvcnRhbnQgdGhhbiB3b3JyeWluZyBhYm91dCB0aGUgc3BlY2lmaWNzIG9mIHdoYXQgIA0K PiBoYXBwZW5zIHdoZW4gdHdvIHNpZ25hbHMgYXJlIHVzZWQgKGFzIGxvbmcgYXMgaXQgaXMgY2xl YXJseSBzcGVjaWZpZWQsICANCj4gb2YgY291cnNlKS4gT3RoZXJzIG1heSBmZWVsIGRpZmZlcmVu dGx5Lg0KDQpodHRwOi8vZGlnYmliLnVia2EudW5pLWthcmxzcnVoZS5kZS92b2xsdGV4dGUvZG9j dW1lbnRzLzE4MjcNCg0KLU1hcnRpbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== From Pasi.Eronen@nokia.com Mon Dec 21 00:58: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 B472C3A687E for ; Mon, 21 Dec 2009 00:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 e8VrTU33pbx6 for ; Mon, 21 Dec 2009 00:58:20 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id CD4D33A67C1 for ; Mon, 21 Dec 2009 00:58:19 -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 nBL8vlr8019198; Mon, 21 Dec 2009 10:57:52 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 10:57:25 +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); Mon, 21 Dec 2009 10:57:21 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 21 Dec 2009 09:57:20 +0100 From: To: , Date: Mon, 21 Dec 2009 09:57:19 +0100 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqBxVzyjJ1EhMYoQwKb4uPMSg4flAAErZfdABDNn8A= Message-ID: <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2009 08:57:21.0072 (UTC) FILETIME=[9B0FEB00:01CA821B] X-Nokia-AV: Clean Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 08:58:21 -0000 Uri Blumenthal wrote: > OK. Karlsruhe server time-outs on me, so no chance to get enlightened > by checking that thread. Please indulge me: the one short compelling > reason why we don't want to say "when two signals are present use this > one and ignore the other" instead of "when two signals are present - > abort connection" - is...? Well, if the spec says "the client MUST not send two signals", then if two signals are present, it's probably safer to abort (since the client is not following the spec anyway, it's hard to guess what its intent was...) Best regards, Pasi (not wearing any hats) From ynir@checkpoint.com Mon Dec 21 01:01: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 8C6EC28C0D7 for ; Mon, 21 Dec 2009 01:01:22 -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 7lgiXGhZufxq for ; Mon, 21 Dec 2009 01:01:21 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7A33C28C0CF for ; Mon, 21 Dec 2009 01:01:20 -0800 (PST) X-CheckPoint: {4B2F3841-10006-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C4B9A29C00B; Mon, 21 Dec 2009 11:01:03 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A70AA29C002; Mon, 21 Dec 2009 11:01:03 +0200 (IST) X-CheckPoint: {4B2F3841-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBL913T7026287; Mon, 21 Dec 2009 11:01:03 +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, 21 Dec 2009 11:01:14 +0200 From: Yoav Nir To: "Blumenthal, Uri - 0662 - MITLL" Date: Mon, 21 Dec 2009 11:01:00 +0200 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqCHCXId4aNo7UgQ3yub4e1gVkb8Q== Message-ID: <5CF5521D-BE6C-4F3F-97DA-5C4B442836BD@checkpoint.com> References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 09:01:23 -0000 It makes the semantics of SCSV unclear. Not a good enough reason in my opin= ion, but still... On Dec 21, 2009, at 2:53 AM, Blumenthal, Uri - 0662 - MITLL wrote: > OK. Karlsruhe server time-outs on me, so no chance to get enlightened by = checking that thread. Please indulge me: the one short compelling reason wh= y we don't want to say "when two signals are present use this one and ignor= e the other" instead of "when two signals are present - abort connection" -= is...? >=20 >=20 > ----- Original Message ----- > From: tls-bounces@ietf.org > To: Steve Checkoway > Cc: tls@ietf.org > Sent: Sun Dec 20 17:39:47 2009 > Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft >=20 > Steve Checkoway wrote: >>=20 >> My point was merely that publication and subsequent implementation of =20 >> the fix is more important than worrying about the specifics of what =20 >> happens when two signals are used (as long as it is clearly specified, = =20 >> of course). Others may feel differently. >=20 > http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1827 >=20 > -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 >=20 > Scanned by Check Point Total Security Gateway. From mrex@sap.com Mon Dec 21 06: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 DE0D828C0E5 for ; Mon, 21 Dec 2009 06:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 YBl+XPQPeUkV for ; Mon, 21 Dec 2009 06: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 9351C28C0D0 for ; Mon, 21 Dec 2009 06:22:01 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBLELf6Y011503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 15:21:41 +0100 (MET) From: Martin Rex Message-Id: <200912211421.nBLELeiU012354@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Mon, 21 Dec 2009 15:21:40 +0100 (MET) In-Reply-To: <4B2D22C6.9090109@extendedsubset.com> from "Marsh Ray" at Dec 19, 9 01:00: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: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Abbreviated Handshake != Renegotiated Handshake 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, 21 Dec 2009 14:22:03 -0000 Marsh Ray wrote: > > Ravi Ganesan wrote: > > > > But regardless even if there is something in existence called a > > "renegotiated abbreviated handshake", I think the distinction between > > 'abbreviated handshakes without renegoitation' which are very very > > widely used should not be confused with 'renegotiated handshakes of any > > kind'. Ravi, your terminology is slightly confusing. Renegotiation refers to a TLS handshake that is performed under protection of an existing TLS session, so the two things you could distinguish are: - renegotiation with a full handshake - renegotiation with an abbreviated handshake (aka session resume) > > Nowhere in the draft does it talk about "abbreviated handshakes". That might be considered a defect, because it is the terminology established by RFC-5246 7.3 Handshake Protocol Overview, Figure 2 http://tools.ietf.org/html/rfc5246#page-37 > > Whether or not a handshake is "abbreviated" has absolutely nothing to do > with whether or not it is an initial or a renegotiation handshake. Correct. -Martin From uri@ll.mit.edu Mon Dec 21 06:35: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 34F663A6767 for ; Mon, 21 Dec 2009 06:35:14 -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 GoQZ1HjmrkYS for ; Mon, 21 Dec 2009 06:35:13 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 46C0B3A67D9 for ; Mon, 21 Dec 2009 06:35:12 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBLEYstH015481; Mon, 21 Dec 2009 09:34:54 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAJmaikl; Mon Dec 21 09:27:27 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Mon, 21 Dec 2009 09:27:27 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'Pasi.Eronen@nokia.com'" , "'tls@ietf.org'" Date: Mon, 21 Dec 2009 09:27:25 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqBxVzyjJ1EhMYoQwKb4uPMSg4flAAErZfdABDNn8AAC5uCIg== Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE85401D@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] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 14:35:14 -0000 SSBzZWUgdGhlIHJlYXNvbmluZywgYW5kIHdoaWxlIG9uZSBjb3VsZCBhcmd1ZSBpbiBmYXZvciBv ZiBndWVzc2luZyAtIHRoZSBsb2dpYyBwcmVzZW50ZWQgaXMgZ29vZCBlbm91Z2ggKGFuZCB0aHVz IHRoZXJlJ3Mgbm8ganVzdGlmaWNhdGlvbiBmb3IgcmUtb3BlbmluZyB0aGlzIGNhbiBhbmQgc3Bl bmRpbmcgbW9yZSB0aW1lIG9uIGl0KS4gDQoNCkkgd2l0aGRyYXcgbXkgb2JqZWN0aW9uLg0KDQpU aGFua3MhDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogUGFzaS5Fcm9u ZW5Abm9raWEuY29tIDxQYXNpLkVyb25lbkBub2tpYS5jb20+DQpUbzogQmx1bWVudGhhbCwgVXJp IC0gMDY2MiAtIE1JVExMOyB0bHNAaWV0Zi5vcmcgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IE1vbiBE ZWMgMjEgMDM6NTc6MTkgMjAwOQpTdWJqZWN0OiBSRTogW1RMU10gU0NTViB2cyBSSSB3aGVuIGJv dGggc3BlY2lmaWVkLiBXYXM6IFVwZGF0ZWQgZHJhZnQNCg0KVXJpIEJsdW1lbnRoYWwgd3JvdGU6 DQoNCj4gT0suIEthcmxzcnVoZSBzZXJ2ZXIgdGltZS1vdXRzIG9uIG1lLCBzbyBubyBjaGFuY2Ug dG8gZ2V0IGVubGlnaHRlbmVkDQo+IGJ5IGNoZWNraW5nIHRoYXQgdGhyZWFkLiBQbGVhc2UgaW5k dWxnZSBtZTogdGhlIG9uZSBzaG9ydCBjb21wZWxsaW5nDQo+IHJlYXNvbiB3aHkgd2UgZG9uJ3Qg d2FudCB0byBzYXkgIndoZW4gdHdvIHNpZ25hbHMgYXJlIHByZXNlbnQgdXNlIHRoaXMNCj4gb25l IGFuZCBpZ25vcmUgdGhlIG90aGVyIiBpbnN0ZWFkIG9mICJ3aGVuIHR3byBzaWduYWxzIGFyZSBw cmVzZW50IC0NCj4gYWJvcnQgY29ubmVjdGlvbiIgLSBpcy4uLj8NCg0KV2VsbCwgaWYgdGhlIHNw ZWMgc2F5cyAidGhlIGNsaWVudCBNVVNUIG5vdCBzZW5kIHR3byBzaWduYWxzIiwgdGhlbiBpZg0K dHdvIHNpZ25hbHMgYXJlIHByZXNlbnQsIGl0J3MgcHJvYmFibHkgc2FmZXIgdG8gYWJvcnQgKHNp bmNlIHRoZQ0KY2xpZW50IGlzIG5vdCBmb2xsb3dpbmcgdGhlIHNwZWMgYW55d2F5LCBpdCdzIGhh cmQgdG8gZ3Vlc3MNCndoYXQgaXRzIGludGVudCB3YXMuLi4pDQoNCkJlc3QgcmVnYXJkcywNClBh c2kNCihub3Qgd2VhcmluZyBhbnkgaGF0cykNCg== From mrex@sap.com Mon Dec 21 07:16: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 A63083A693E for ; Mon, 21 Dec 2009 07:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 0WoLHtFX0lzf for ; Mon, 21 Dec 2009 07:16: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 ABE573A6A07 for ; Mon, 21 Dec 2009 07:16:22 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBLFG2q3001041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 16:16:02 +0100 (MET) From: Martin Rex Message-Id: <200912211516.nBLFG1Rw015709@fs4113.wdf.sap.corp> To: uri@ll.mit.edu (Blumenthal Uri - 0662 - MITLL) Date: Mon, 21 Dec 2009 16:16:01 +0100 (MET) In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> from "Blumenthal, Uri - 0662 - MITLL" at Dec 20, 9 07:53: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] SCSV vs RI when both specified. Was: Updated 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: Mon, 21 Dec 2009 15:16:30 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > > Please indulge me: the one short compelling reason why we don't want > to say "when two signals are present use this one and ignore the other" > instead of "when two signals are present - abort connection" - is...? I do not think such a reason exists. The justification that has been given so far is "because that is what the document says". If you look at the document from the perspective of formal correctness proofing, then this is justification is based on a defect in the document. > > > http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1827 > > OK. Karlsruhe server time-outs on me, so no chance to get enlightened > by checking that thread. That URL refers to a publication called "Would you ever risk a non-monomorphic specication?" It is about formal correctness proofing of specifications and implementations. I am _not_ an expert in the field of formal correction proofing, and in theoretical math stuff, I am more of a practical type of person. But I have a good understanding of some of the principles and methodologies involved. In 1996 I shared office for 5 month with a student from the University of Karlsruhe who did his master thesis at our company developing a formal specification for the authorization model in our application software and doing a formal correctness proof, using a tool called "Karlsruhe Interactive Verifier (KIV)" which was also used for above document. This resulted in a number of fixes to our design and implementation. I found the underlying concepts and methodologies so interesting and intriguing that I started implmenting a "generic" gssapi-mechanism in order to locate inconsistencies and ambiguities in the GSS-API v2 during the following 2 years, and get them fixed in the IETF CAT WG before publishing GSS-API v2. (the most part of this generic implementation was re-used to build my gssntlm.dll/gsskrb5.dll wrappers for Microsoft NTLM and Kerberos 5 SSP to provide a GSS-API v2 compliant API ftp://ftp.sap.com/pub/ietf-work/gssapi/gsskrb5/) The methodology of the KIV tool is to create an implementation of the given specification, and it asks the operater to manually ("interactively") resolve all ambiguities and conflicts that prevent an full implementation of the spec. The KIV tool will actually output a 100% bugfree implementation of the spec (back then you could ask for C or C++ output). Probably the biggest and most time-consuming part for tool-based formal verification is the translation from a specification that mere humans understand into predicate logic (and backwards for all the resolved problems). What formal proofing does _not_ provide is coming up with specification that are actually useful and do what you want. The most intriguing part is, that the methodology not only works for the spec -> code transformation, it can also be used for the solution-architecture -> spec transformation. -Martin From marsh@extendedsubset.com Mon Dec 21 08: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 ED8083A67D9 for ; Mon, 21 Dec 2009 08:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXQGKEKL9eLE for ; Mon, 21 Dec 2009 08:28:44 -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 107FF3A67F6 for ; Mon, 21 Dec 2009 08:28:44 -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 1NMl7S-0000F2-SE; Mon, 21 Dec 2009 16:28:27 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 53FFF603A; Mon, 21 Dec 2009 16:28:25 +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: U2FsdGVkX18rv0LGphFasZI4EV8F2DhIDWkxBVkpmCU= Message-ID: <4B2FA22D.2090800@extendedsubset.com> Date: Mon, 21 Dec 2009 10:28:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Blumenthal, Uri - 0662 - MITLL" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@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 Cc: "'tls@ietf.org'" Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 16:28:45 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > The only purpose of any protocol is to allow entities to communicate > (under a given set of constraints). Thus every effort SHOULD be > invested to provide this capability whenever possible. TLS is a cryptographic data security protocol. "Allowing entities to communicate" takes a back seat to the primary goal of preventing unauthorized communication. > If the > protocol spec demands aborting connection, it better have a damn good > reason to do so - and more substantive than "some Steve decided it > doesn't really matter to him if the peers connect or not". How about "remote endpoint doesn't pass the bozo test"? > Personal curiosity - what kind of work do you do? (Feel free to > answer in a private email or to ignore altogether.) I do software development (and security research) work on PhoneFactor, a product/service for doing two-factor authentication with ordinary phones. > I'm shocked that nobody else seems to pick on this. Is it that > mid-weekend thing, or am I the only one who cares whether the peer > would establish or refuse connection?! Yes, I care greatly that the peer refuses any connection that looks the least bit funny. - Marsh From mike-list@pobox.com Mon Dec 21 09:04: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 EC1453A6A46 for ; Mon, 21 Dec 2009 09:04:25 -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.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOelKL3qtZRE for ; Mon, 21 Dec 2009 09:04:25 -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 DFB443A6A0B for ; Mon, 21 Dec 2009 09:04:23 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 1E7C1A8033 for ; Mon, 21 Dec 2009 12:04: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=BVPbX/ZBxUgX z4hImvIDLelpD8U=; b=hPfZHu0ZSexCbN/sutDEezYab8CY3e1nyLRF0323/ifu bG+usfieLiMWSB2F08novA3cT1QubQB2dJGVTXTYL605mbPug3WHyW0rYGF2rKRg ZCsWa8s2u6DmOt3f78/ZA+IHRvJQyyXNWY54LW/JoxxsDgje+hoHjv8NnBwiJww= 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=QmQruc gpmzxiXg+v06HPHivLZXm1uDi2A6KGLK2CcvRYD+MWhVs22vUC7sXF1RMRmoZP0F kAJld4CUrQw9+BO2NhNro/5kirP6/YSblmsFq3sAj3zPSjbp/W9RpUDuT0uri3NW 25EZvTSj4vV4Ifds1w3CpUSvbSnq7RFutM7kU= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 101B9A8032 for ; Mon, 21 Dec 2009 12:04: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 932CEA8031 for ; Mon, 21 Dec 2009 12:04:06 -0500 (EST) Message-ID: <4B2FAAFB.5090908@pobox.com> Date: Mon, 21 Dec 2009 09:06:03 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D96D941C-EE52-11DE-A8C1-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 17:04:26 -0000 So what's the consensus on this? 1) client MUST not send both signals, and a server MUST abort if it sees both or 2) client MAY send both signals, and the server MUST ignore SCSV when RI is present I prefer (2) since there is no security problem with the client sending both -- the only problem is the current wording in the spec. Remember the spec is currently a DRAFT, and that means it is open to changes! I don't understand the reluctance to clarify this. Mike Pasi.Eronen@nokia.com wrote: > Uri Blumenthal wrote: > >> OK. Karlsruhe server time-outs on me, so no chance to get enlightened >> by checking that thread. Please indulge me: the one short compelling >> reason why we don't want to say "when two signals are present use this >> one and ignore the other" instead of "when two signals are present - >> abort connection" - is...? > > Well, if the spec says "the client MUST not send two signals", then if > two signals are present, it's probably safer to abort (since the > client is not following the spec anyway, it's hard to guess > what its intent was...) > > Best regards, > Pasi > (not wearing any hats) From lists@drh-consultancy.demon.co.uk Mon Dec 21 09:37: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 82E113A69FC for ; Mon, 21 Dec 2009 09:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=-1.069, 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 e5Sc4nXkEkKG for ; Mon, 21 Dec 2009 09:37: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 4BA9F3A695D for ; Mon, 21 Dec 2009 09:37:58 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:54810 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 1NMmCS-0006w3-3z for tls@ietf.org (return-path ); Mon, 21 Dec 2009 17:37:40 +0000 Message-ID: <4B2FB265.5040203@drh-consultancy.demon.co.uk> Date: Mon, 21 Dec 2009 17:37:41 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> In-Reply-To: <4B2FAAFB.5090908@pobox.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 17:37:59 -0000 Michael D'Errico wrote: > So what's the consensus on this? > > 1) client MUST not send both signals, and a server MUST abort > if it sees both > > or > > 2) client MAY send both signals, and the server MUST ignore > SCSV when RI is present > > I prefer (2) since there is no security problem with the client sending > both -- the only problem is the current wording in the spec. Remember > the spec is currently a DRAFT, and that means it is open to changes! I > don't understand the reluctance to clarify this. > I'd have a minor preference for #2 but I'd also vote for option #3 3) Couldn't give a toss just get the fecking spec finalised, OK? ;-) 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 Dec 21 09:50: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 E0F383A6A74 for ; Mon, 21 Dec 2009 09:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 pqcW7Qnf-AeN for ; Mon, 21 Dec 2009 09:50: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 099EA3A68AA for ; Mon, 21 Dec 2009 09:50:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBLHoDBC027870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 18:50:13 +0100 (MET) From: Martin Rex Message-Id: <200912211750.nBLHoC6a024954@fs4113.wdf.sap.corp> To: Pasi.Eronen@nokia.com Date: Mon, 21 Dec 2009 18:50:12 +0100 (MET) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 21, 9 09:57: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] SCSV vs RI when both specified. Was: Updated 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: Mon, 21 Dec 2009 17:50:33 -0000 Pasi.Eronen@nokia.com wrote: > > Uri Blumenthal wrote: > > > OK. Karlsruhe server time-outs on me, so no chance to get enlightened > > by checking that thread. Please indulge me: the one short compelling > > reason why we don't want to say "when two signals are present use this > > one and ignore the other" instead of "when two signals are present - > > abort connection" - is...? > > Well, if the spec says "the client MUST not send two signals", then if > two signals are present, it's probably safer to abort (since the > client is not following the spec anyway, it's hard to guess > what its intent was...) There would only be an ambiguity when the signal could indicate two different semantics. The description of the semantics of TLS_RENEGO_PROTECTION_REQUEST in draft-tls-renegotiation-02 is defective and needs to be fixed. The currently flawed defintion for TLS_RENEGO_PROTECTION_REQUEST is what caused this: http://www.ietf.org/mail-archive/web/tls/current/msg05155.html http://www.ietf.org/mail-archive/web/tls/current/msg05186.html and resulted in this text in draft-tls-renegotiation-02.txt: 6.1 Client Considerations [TODO: this needs a discussion of what signal to send in legacy renegotiation to match the resolution of the paired TODO in Section 4.] The purpose of TLS_RENEGO_PROTECTION_REQUEST is to request _ONLY_ the new handshake semantics (which first-of-all concerns those peers in the communication that are performing a renegotiation handshake). The resistence to adopting the correct semantics for TLS_RENEGO_PROTECTION_REQUEST is probably because from the viewpoint of formal correctness proofing, the correct definition implies that this signal MUST be asserted on every ClientHello (because the absence, that would then indicate "old handshake semantics" would be incompatible with the presence of an TLS extension RI. But for the old renegotiation scenario, the result of the correct definition of TLS_RENEGO_PROTECTION_REQUEST would provide an obvious, intuitive and fully backwards interoperable solution. In addition, everyone would save code, and the solution would become less complex. What makes me feel slightly uneasy is that some people think the above is a special case that needs to be seperately addressed in the document. With a clean architecture, that is no special case. The problem with draft-tls-renegotiation-02 is, that it comes without architecture. It is an implementation of an unspecified solution architecture. And that leads to discussions about belief, rather than characteristics of a specific (spec-level) implementation of a solution architecture, where it is possible to check implementation details with methodologies used in formal correctness proofs. The reason why the TLS renegotiation vulnerability was not noticed for so long is quite related to this. The SSL and TLS protocols completely failed to describe its architecture, otherwise the defect would have been obvious. Once I had described the architecture of TLS renegotiation to Larry and Nico in the discussion about channel bindings early November, it became obvious to me, from last paragraph of this: http://www.ietf.org/mail-archive/web/tls/current/msg03922.html to this: http://www.ietf.org/mail-archive/web/tls/current/msg03928.html And that applies to all other problems recently discussed. The lack of an (explanation of) the architecture hides most of the problems, like identity change during renegotiation, the possibility of application data interleaved with renegotiation handshakes, the effect of TLS session resumption and TLS session caching strategies on certificate path validation. -Martin From mike-list@pobox.com Mon Dec 21 09:53: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 425973A6A7E for ; Mon, 21 Dec 2009 09:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIzPH1Bzzz2L for ; Mon, 21 Dec 2009 09:53: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 703B03A68AA for ; Mon, 21 Dec 2009 09:53: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 E8660A8504 for ; Mon, 21 Dec 2009 12:53: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=IAd33IPqnNeQ aUOMcBmlT2tWIAE=; b=o0O2Ei5qtECJ+e7vcok5qIILHs4r9zZ88j3JWSGFn6uG +2ZzAz3nc1ZwiDlcD9mc63wyTwZRp4N85GPxq/6jz28emkgBUJL3KUX23rh+9rna xKqV8lNnfJQgXpuWFRxTWujHLnTE5D6CjJOY10lhZay2TU00A+bOQChZoKOBoxQ= 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=WSpHmd Vtec9WW7UPCVoKI2nAycLN19HIp5PmTCKg8eQFzCEvEQR4V/i7BxugSRj2UEdbpm I6dVpaGYcRt6uHIpfZyEk8GA33paW2d7m+Efy2VNFKolRXH6q5sStbkFKnrv9Hal op1qlQ5/V2SkleIFeMegbLLHyXPnK4eTX2jmk= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E3885A8503 for ; Mon, 21 Dec 2009 12:53: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 3AACDA84FC for ; Mon, 21 Dec 2009 12:53:23 -0500 (EST) Message-ID: <4B2FB68C.1000400@pobox.com> Date: Mon, 21 Dec 2009 09:55:24 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> In-Reply-To: <4B2FB265.5040203@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: BED68A9E-EE59-11DE-99F0-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 21 Dec 2009 17:53:46 -0000 I agree we need to publish ASAP, but if consensus is (1), then I need to change my (running) code since it currently does (2). Mike Dr Stephen Henson wrote: > Michael D'Errico wrote: >> So what's the consensus on this? >> >> 1) client MUST not send both signals, and a server MUST abort >> if it sees both >> >> or >> >> 2) client MAY send both signals, and the server MUST ignore >> SCSV when RI is present >> >> I prefer (2) since there is no security problem with the client sending >> both -- the only problem is the current wording in the spec. Remember >> the spec is currently a DRAFT, and that means it is open to changes! I >> don't understand the reluctance to clarify this. >> > > I'd have a minor preference for #2 but I'd also vote for option #3 > > 3) Couldn't give a toss just get the fecking spec finalised, OK? > > ;-) > > Steve. From marsh@extendedsubset.com Mon Dec 21 10: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 137CA3A6A80 for ; Mon, 21 Dec 2009 10:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0RQkNM4t7hR for ; Mon, 21 Dec 2009 10:02: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 5157E3A6A72 for ; Mon, 21 Dec 2009 10:02: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 1NMmZn-0001Fi-QY; Mon, 21 Dec 2009 18:01:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 87CD7603A; Mon, 21 Dec 2009 18:01: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/dQs9duNhVdWu7+/9gPWp73xiVjKmUXgA= Message-ID: <4B2FB80E.8080300@extendedsubset.com> Date: Mon, 21 Dec 2009 12:01:50 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> <4B2FB68C.1000400@pobox.com> In-Reply-To: <4B2FB68C.1000400@pobox.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] SCSV vs RI when both specified - consensus? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2009 18:02:05 -0000 Michael D'Errico wrote: > I agree we need to publish ASAP, but if consensus is (1), then I need > to change my (running) code since it currently does (2). Is everybody OK with this wording? (it's the more lenient choice): > Clients MUST NOT put multiple occurrences of an RI extension in the > same Client Hello message. A client MAY specify the SCSV in the same > Client Hello message as an RI extension (the SCSV will be effectively > ignored). > > A server receiving a Client Hello containing multiple RI extensions > MUST generate a fatal "decode_error" alert and terminate the > connection. A server receiving a Client Hello containing the SCSV > and an RI extension is to interpret the RI as usual and ignore the > SCSV. We'll have to fix the conflict with the current: > This SCSV is not a true cipher suite and cannot be negotiated. It > merely has exactly the same semantics as an empty "renegotiation_info" > extension. to something like: > This SCSV is not a true cipher suite and cannot be negotiated, it > has similar semantics as an empty "renegotiation_info" extension. - Marsh From noskov@microsoft.com Mon Dec 21 10:21: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 9F2DA3A6A88 for ; Mon, 21 Dec 2009 10:21:42 -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 DQaRINvQH3xJ for ; Mon, 21 Dec 2009 10:21:41 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id AC44A3A6A89 for ; Mon, 21 Dec 2009 10:21:41 -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; Mon, 21 Dec 2009 10:21:57 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 21 Dec 2009 10:21:24 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 21 Dec 2009 10:21:24 -0800 From: Nasko Oskov To: Marsh Ray , Michael D'Errico Thread-Topic: [TLS] SCSV vs RI when both specified - consensus? Thread-Index: AQHKgmfWpzk3JyyCXke0BQHUh/lnN5Fvz5rw Date: Mon, 21 Dec 2009 18:20:16 +0000 Deferred-Delivery: Mon, 21 Dec 2009 18:21:00 +0000 Message-ID: References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> <4B2FB68C.1000400@pobox.com> <4B2FB80E.8080300@extendedsubset.com> In-Reply-To: <4B2FB80E.8080300@extendedsubset.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] SCSV vs RI when both specified - consensus? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2009 18:21:42 -0000 Marsh Ray wrote: >Michael D'Errico wrote: >> I agree we need to publish ASAP, but if consensus is (1), then I need=20 >> to change my (running) code since it currently does (2). > > >Is everybody OK with this wording? (it's the more lenient choice): > >> Clients MUST NOT put multiple occurrences of an RI extension in the=20 >> same Client Hello message. A client MAY specify the SCSV in the same=20 >> Client Hello message as an RI extension (the SCSV will be effectively=20 >> ignored). >> >> A server receiving a Client Hello containing multiple RI extensions=20 >> MUST generate a fatal "decode_error" alert and terminate the=20 >> connection. A server receiving a Client Hello containing the SCSV and=20 >> an RI extension is to interpret the RI as usual and ignore the SCSV. I generally agree with this wording. I find the sentence describing multipl= e RI extensions behavior redundand, since this is already part of RFC5246: Section 7.4.1.4: There MUST NOT be more than one extension of the same type. >We'll have to fix the conflict with the current: >> This SCSV is not a true cipher suite and cannot be negotiated. It=20 >> merely has exactly the same semantics as an empty "renegotiation_info" >> extension. > >to something like: >> This SCSV is not a true cipher suite and cannot be negotiated, it has=20 >> similar semantics as an empty "renegotiation_info" extension. Agreed. Nasko From ravi@findravi.com Mon Dec 21 10:27: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 8B6663A6889 for ; Mon, 21 Dec 2009 10:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 V7uKCfTzf9dx for ; Mon, 21 Dec 2009 10:27: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 574203A6405 for ; Mon, 21 Dec 2009 10:27:57 -0800 (PST) Received: by pzk6 with SMTP id 6so3927193pzk.29 for ; Mon, 21 Dec 2009 10:27:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.163.16 with SMTP id l16mr1519811wae.39.1261420058293; Mon, 21 Dec 2009 10:27:38 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Dec 2009 10:27:38 -0800 Message-ID: <3561bdcc0912211027l642d7085kf825965d3b0d6ec9@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=00504502f58f7cb807047b413ec8 Subject: Re: [TLS] TLS Digest, Vol 65, Issue 88 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2009 18:27:58 -0000 --00504502f58f7cb807047b413ec8 Content-Type: text/plain; charset=UTF-8 > > > > Ravi, your terminology is slightly confusing. Renegotiation refers > to a TLS handshake that is performed under protection of an existing > TLS session, so the two things you could distinguish are: > Martin, Point well taken. Thx, Ravi p.s. I prefer not to think of the handshake happening "under protection" of previous session. Another example of this is in current draft which says: "The handshake is in the clear to the attacker but encrypted over the attacker's TLS connection to the server." The handshake itself is always of course is in the clear, certain values in it are encrypted with certain keys. And in some cases this results in binding to previous sessions. This sounds nitpicky, but I only say this because perfectly smart security people with some knowledge of SSL can read sentences like above to assume the entire handshake (including client_random and server_random) is encrypted. --00504502f58f7cb807047b413ec8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Ravi, your terminology is slightly confusing. =C2=A0Renegotiation refers to a TLS handshake that is performed under protection of an existing
TLS session, so the two things you could distinguish are:
<= div>
Martin, Point well taken. Thx, Ravi

p.s. I prefer not to thi= nk of the handshake happening "under protection" of previous sess= ion. Another example of this is in current draft which says: "The hand= shake is in the clear to the attacker but encrypted over the attacker's= TLS connection to the server." The handshake itself is always of cour= se is in the clear, certain values in it are encrypted with certain keys. A= nd in some cases this results in binding to previous sessions. This sounds = nitpicky, but I only say this because perfectly smart security people with = some knowledge of SSL can read sentences like above to assume the entire ha= ndshake (including client_random and server_random) is encrypted.
--00504502f58f7cb807047b413ec8-- From marsh@extendedsubset.com Mon Dec 21 10:46: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 4128B3A6AA7 for ; Mon, 21 Dec 2009 10:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDfGe8LCXMcI for ; Mon, 21 Dec 2009 10:46: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 357413A69CA for ; Mon, 21 Dec 2009 10:46: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 1NMnHC-0008Gh-Mm; Mon, 21 Dec 2009 18:46:38 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5E0A8603A; Mon, 21 Dec 2009 18:46:37 +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+LVQuQyDaR13IsS4VOcyVh+NA6ch8Cy9Y= Message-ID: <4B2FC291.8010809@extendedsubset.com> Date: Mon, 21 Dec 2009 12:46:41 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nasko Oskov References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> <4B2FB68C.1000400@pobox.com> <4B2FB80E.8080300@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 Cc: "tls@ietf.org" Subject: Re: [TLS] SCSV vs RI when both specified - consensus? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2009 18:46:56 -0000 Nasko Oskov wrote: > Marsh Ray wrote: >>> A server receiving a Client Hello containing multiple RI extensions >>> MUST generate a fatal "decode_error" alert and terminate the >>> connection. A server receiving a Client Hello containing the SCSV and >>> an RI extension is to interpret the RI as usual and ignore the SCSV. > > I generally agree with this wording. I find the sentence describing multiple > RI extensions behavior redundand, since this is already part of RFC5246: > > Section 7.4.1.4: > There MUST NOT be more than one extension of the same type. Oh yeah. It's also in RFC 3546 'TLS Extensions'. I looked for it the other day but didn't see it. Now I can't find where it says what to do when it happens. - Marsh From mrex@sap.com Mon Dec 21 10: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 12D0428C124 for ; Mon, 21 Dec 2009 10:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 VZWsC7IGhfJt for ; Mon, 21 Dec 2009 10:56: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 EA82228C101 for ; Mon, 21 Dec 2009 10:56:12 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBLItss4026259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 19:55:54 +0100 (MET) From: Martin Rex Message-Id: <200912211855.nBLItr57029345@fs4113.wdf.sap.corp> To: ravi@findravi.com (Ravi Ganesan) Date: Mon, 21 Dec 2009 19:55:53 +0100 (MET) In-Reply-To: <3561bdcc0912211027l642d7085kf825965d3b0d6ec9@mail.gmail.com> from "Ravi Ganesan" at Dec 21, 9 10:27:38 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 Digest, Vol 65, Issue 88 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, 21 Dec 2009 18:56:14 -0000 Ravi Ganesan wrote: > > > > > Ravi, your terminology is slightly confusing. Renegotiation refers > > to a TLS handshake that is performed under protection of an existing > > TLS session, so the two things you could distinguish are: > > > > - renegotiation with a full handshake > > - renegotiation with an abbreviated handshake (aka session resume) > > I prefer not to think of the handshake happening "under protection" of > previous session. Another example of this is in current draft which says: > "The handshake is in the clear to the attacker but encrypted over the > attacker's TLS connection to the server." The handshake itself is always of > course is in the clear, certain values in it are encrypted with certain > keys. And in some cases this results in binding to previous sessions. This > sounds nitpicky, but I only say this because perfectly smart security people > with some knowledge of SSL can read sentences like above to assume the > entire handshake (including client_random and server_random) is encrypted. We might be talking past each other to some extent. For a renegotiation handhshake, the entire handshake is encrypted, including client_random and server_random, which means that anybody watching it on the network can not see anything else than the TLS record protocol on the outside (but he can see the ContentType of the records). The communication peers can decrypt the communication, of course. In the specific case of the one attack described in draft-ietf-tls-renegotiation the MitM encrypts the handshake data received from the peer and sends it to the server into a renegotiation handshake, and the MitM decrypts all handshake data received from the server and sends it to the client in the clear. If you discount the special case of the RSA-encrypted premaster secret, there are _no_ values in the handshake data that are encrypted "with certain keys". In the SSL&TLS design, encryption of the communication happens exclusively at the record layer (using records with sequence numbers). -Martin From marsh@extendedsubset.com Mon Dec 21 10:59: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 CAD513A697D for ; Mon, 21 Dec 2009 10:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzoe28VqRT0L for ; Mon, 21 Dec 2009 10:59: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 196943A6834 for ; Mon, 21 Dec 2009 10:59: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 1NMnTE-00063u-M2; Mon, 21 Dec 2009 18:59:04 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 6C4CE603A; Mon, 21 Dec 2009 18:59: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/2lKMaAh+63ghkhoRmWb76tLPYcxD6Gis= Message-ID: <4B2FC57B.4070908@extendedsubset.com> Date: Mon, 21 Dec 2009 12:59:07 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ravi Ganesan References: <3561bdcc0912211027l642d7085kf825965d3b0d6ec9@mail.gmail.com> In-Reply-To: <3561bdcc0912211027l642d7085kf825965d3b0d6ec9@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] Handshake not under 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, 21 Dec 2009 18:59:21 -0000 Ravi Ganesan wrote: > > Ravi, your terminology is slightly confusing. Renegotiation refers > to a TLS handshake that is performed under protection of an existing > TLS session, so the two things you could distinguish are: > > Martin, Point well taken. Thx, Ravi > > p.s. I prefer not to think of the handshake happening "under protection" > of previous session. Another example of this is in current draft which > says: "The handshake is in the clear to the attacker but encrypted over > the attacker's TLS connection to the server." The handshake itself is > always of course is in the clear, certain values in it are encrypted > with certain keys. And in some cases this results in binding to previous > sessions. This sounds nitpicky, but I only say this because perfectly > smart security people with some knowledge of SSL can read sentences like > above to assume the entire handshake (including client_random and > server_random) is encrypted. +1. There is no "protection" being provided. People who are thinking renegotiation provides real security for client certificates are somewhat misguided. At the TLS level, it's possible for the current session to be anon-anon-DH, which provides no protection. In practice, client apps will hand over the plaintext client certificate to any MitM that asks for it. - Marsh From mrex@sap.com Mon Dec 21 11:18: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 EF1053A690D for ; Mon, 21 Dec 2009 11:18:20 -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 QOp8uVrDIBYv for ; Mon, 21 Dec 2009 11:18: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 BC1D63A67FA for ; Mon, 21 Dec 2009 11:18:19 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBLJHxfg000537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 20:17:59 +0100 (MET) From: Martin Rex Message-Id: <200912211917.nBLJHxSG000534@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Mon, 21 Dec 2009 20:17:59 +0100 (MET) In-Reply-To: <4B2FC57B.4070908@extendedsubset.com> from "Marsh Ray" at Dec 21, 9 12: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: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 19:18:21 -0000 Marsh Ray wrote: > > Ravi wrote: > > > > p.s. I prefer not to think of the handshake happening "under protection" > > of previous session. Another example of this is in current draft which > > says: "The handshake is in the clear to the attacker but encrypted over > > the attacker's TLS connection to the server." The handshake itself is > > always of course is in the clear, certain values in it are encrypted > > with certain keys. And in some cases this results in binding to previous > > sessions. This sounds nitpicky, but I only say this because perfectly > > smart security people with some knowledge of SSL can read sentences like > > above to assume the entire handshake (including client_random and > > server_random) is encrypted. > > +1. > > There is no "protection" being provided. People who are thinking > renegotiation provides real security for client certificates are > somewhat misguided. I disagree to this conclusion about client identity protection. > > At the TLS level, it's possible for the current session to be > anon-anon-DH, which provides no protection. And which rfc-5246 requires to _not_ request a client certificate: 7.4.4. Certificate Request When this message will be sent: A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. > > In practice, client apps will hand over the plaintext client certificate > to any MitM that asks for it. Unfortunately, this observation is very true for most of the installed base. It may easily be wrong for clients that do care about client identity protection and require a TLS renegotiation before sending a client certificate. The client certificate itself is sent with whatever protection the record layer currently applies (non on an initial handshake) without any kind of additional protection in a Certificate message from the client to the server if the server includes a CertificateRequest message between ServerHello and ServerHelloDone. At that point, the Server is _not_ authenticated. The server has already sent his "Certificate" message (containing the server certificate), but that could be fake. Only when the TLS handshake succeeds, the client knows that the provided server certificate wasn't fake -- and at that point the application could decide whether it wants to reveal its identity to that authenticated server through TLS renegotiation. Client identity protection through renegotiation _can_ be used in a secure fashion. There is no guidance in the TLS spec how to do it, though, and most existing clients are willing to send a client certificate in any handshake. A number of clients will send their client certificate to servers on request in the initial handshake even when the server doesn't indicate that it trusts one of the trust anchors necessary to verify that client cert. (But the latter is a mitigation strategy at best). -Martin From marsh@extendedsubset.com Mon Dec 21 11: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 1554C3A6AA6 for ; Mon, 21 Dec 2009 11:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClauNkg1Fcbl for ; Mon, 21 Dec 2009 11:37:19 -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 C30D73A67FA for ; Mon, 21 Dec 2009 11:37:19 -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 1NMo3z-0008JV-Ar; Mon, 21 Dec 2009 19:37:03 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 455BD603A; Mon, 21 Dec 2009 19:37: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: U2FsdGVkX19vPCey7eWjWBU9uRJae96kDWB03NMwxpo= Message-ID: <4B2FCE60.3020507@extendedsubset.com> Date: Mon, 21 Dec 2009 13:37:04 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912211917.nBLJHxSG000534@fs4113.wdf.sap.corp> In-Reply-To: <200912211917.nBLJHxSG000534@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: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 19:37:21 -0000 Martin Rex wrote: > Marsh Ray wrote: > >> At the TLS level, it's possible for the current session to be >> anon-anon-DH, which provides no protection. > > And which rfc-5246 requires to _not_ request a client certificate: > > 7.4.4. Certificate Request > > When this message will be sent: > > A non-anonymous server can optionally request a certificate from > the client, if appropriate for the selected cipher suite. The client cert is requested in the renegotiating handshake, not the initial one. An anon-anon-DH session provides no "protection" for the client cert passed in renegotiation. But it probably makes some people feel more secure to not see the details (usernames, emails, phone numbers, street addresses) flying by on the wire. >> In practice, client apps will hand over the plaintext client certificate >> to any MitM that asks for it. > > Unfortunately, this observation is very true for most of the installed base. > > It may easily be wrong for clients that do care about client identity > protection and require a TLS renegotiation before sending a client > certificate. I haven't yet found a client that requires renegotiation before supplying a client cert. I have seen common recommendations to have the server ask for it by renegotiation, as if that were a secure solution. > The client certificate itself is sent with whatever protection the > record layer currently applies (non on an initial handshake) without > any kind of additional protection in a Certificate message from the client > to the server if the server includes a CertificateRequest message > between ServerHello and ServerHelloDone. > > At that point, the Server is _not_ authenticated. The server has > already sent his "Certificate" message (containing the server certificate), > but that could be fake. Only when the TLS handshake succeeds, the > client knows that the provided server certificate wasn't fake Yep. > -- and > at that point the application could decide whether it wants to > reveal its identity to that authenticated server through TLS > renegotiation. There are several significant points during the handshake that seem to require special application-layer processing. Rarely do we see one callback implemented perfectly, much less for two handshakes! > Client identity protection through renegotiation _can_ be used in > a secure fashion. It could be done securely if the application layer specified its operation thoroughly. HTTPS does not, I wonder if any do? > There is no guidance in the TLS spec how to do it, > though, and most existing clients are willing to send a client > certificate in any handshake. That's my point exactly. > A number of clients will send > their client certificate to servers on request in the initial > handshake even when the server doesn't indicate that it trusts > one of the trust anchors necessary to verify that client cert. > (But the latter is a mitigation strategy at best). Seems like the legit server's list of trust anchors would be trivial to discover. - Marsh From mrex@sap.com Mon Dec 21 11:49: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 1AD303A692A for ; Mon, 21 Dec 2009 11:49:26 -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 QdIv3TxLhP6N for ; Mon, 21 Dec 2009 11:49: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 D5A5C3A68C3 for ; Mon, 21 Dec 2009 11:49:24 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBLJn5FU000289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 20:49:05 +0100 (MET) From: Martin Rex Message-Id: <200912211949.nBLJn4H8002441@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Mon, 21 Dec 2009 20:49:04 +0100 (MET) In-Reply-To: <4B2FCE60.3020507@extendedsubset.com> from "Marsh Ray" at Dec 21, 9 01:37:04 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: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 19:49:26 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > Marsh Ray wrote: > > > >> At the TLS level, it's possible for the current session to be > >> anon-anon-DH, which provides no protection. > > > > And which rfc-5246 requires to _not_ request a client certificate: > > > > 7.4.4. Certificate Request > > > > When this message will be sent: > > > > A non-anonymous server can optionally request a certificate from > > the client, if appropriate for the selected cipher suite. > > The client cert is requested in the renegotiating handshake, not the > initial one. An anon-anon-DH session provides no "protection" for the > client cert passed in renegotiation. > > But it probably makes some people feel more secure to not see the > details (usernames, emails, phone numbers, street addresses) flying by > on the wire. OK. You are correct. That provision in 7.4.4. is about the _current_ handshake only and refers to the fact that a server has sent a "Certificate" message prior to CertificateRequest. Since at the point of the handshake, the Server is _not_ authenticated. There could have been a certificate path validation of the server certificate, but there is no proof yet, that the alleged server knows the necessary private key to the presented certificate, so this restriction in 7.4.4. does not provide security. -Martin From mike-list@pobox.com Mon Dec 21 12:31: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 E256B28C161 for ; Mon, 21 Dec 2009 12:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZaxFNM6fa2f for ; Mon, 21 Dec 2009 12:31:50 -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 DBED428C15F for ; Mon, 21 Dec 2009 12:31:49 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 10BCB8AA00 for ; Mon, 21 Dec 2009 15: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=FO9H8ePaTjgn 1NmnKycNakA3d7o=; b=NCDLgXTgJfNlp4n2y6NHcCssO7Bl89lc1myI17oAS1Do nZ/ls/LiUWpyD2EuVyvIdMmd/BSIPV63Ur1syr7x+X2XzNk92AZQf29fDOb5KmL/ bAiLv8l0wHTroXA5f3gIrMiT7YyzcTiKBZOXvgM9gCA9XThZHn+NUWhnPFkPf5c= 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=WkGoO6 cwcUq1UCTQfHcz4QrANjARhmVBblBAd9yEgAjAZZwFUik8/XilH1/IlGUrWBBWk8 IXvzgwi6lzVhegSqnYdw5fzgupVgm5W9JPp+aTVB+nhAKH0GReP6npNsOzQ5Dx6u EcrOCliNpkmZ3oFBPmofq1XBvIF/aIqH50Mko= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0D4038A9FF for ; Mon, 21 Dec 2009 15: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-quonix.pobox.com (Postfix) with ESMTPSA id 80E388A9FE for ; Mon, 21 Dec 2009 15:31:32 -0500 (EST) Message-ID: <4B2FDB93.4090105@pobox.com> Date: Mon, 21 Dec 2009 12:33:23 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200912211949.nBLJn4H8002441@fs4113.wdf.sap.corp> In-Reply-To: <200912211949.nBLJn4H8002441@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D3D22C9E-EE6F-11DE-B7EE-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 20:31:51 -0000 Martin Rex wrote: > Marsh Ray wrote: >> Martin Rex wrote: >>> Marsh Ray wrote: >>> >>>> At the TLS level, it's possible for the current session to be >>>> anon-anon-DH, which provides no protection. >>> And which rfc-5246 requires to _not_ request a client certificate: >>> >>> 7.4.4. Certificate Request >>> >>> When this message will be sent: >>> >>> A non-anonymous server can optionally request a certificate from >>> the client, if appropriate for the selected cipher suite. >> The client cert is requested in the renegotiating handshake, not the >> initial one. An anon-anon-DH session provides no "protection" for the >> client cert passed in renegotiation. >> >> But it probably makes some people feel more secure to not see the >> details (usernames, emails, phone numbers, street addresses) flying by >> on the wire. > > OK. You are correct. > > That provision in 7.4.4. is about the _current_ handshake only > and refers to the fact that a server has sent a "Certificate" > message prior to CertificateRequest. Since at the point of > the handshake, the Server is _not_ authenticated. There could have > been a certificate path validation of the server certificate, > but there is no proof yet, that the alleged server knows the > necessary private key to the presented certificate, so this > restriction in 7.4.4. does not provide security. If a DHE cipher suite is used, then the server can be authenticated using only Certificate and ServerKeyExchange. With RSA cipher suites, you are correct that a client doesn't authenticate the server until Finished verifies. Mike From mike-list@pobox.com Mon Dec 21 12:56: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 A5AD33A6881 for ; Mon, 21 Dec 2009 12:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2BYfqS8mTlO for ; Mon, 21 Dec 2009 12:56:20 -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 A8C683A67EA for ; Mon, 21 Dec 2009 12:56:19 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 510C58AC22 for ; Mon, 21 Dec 2009 15:56:03 -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=0rGw1Vy97z/G 8EOt1I9XD63wFGQ=; b=CkFzqaH7/1oASZ2RHqwKUomo++ozwZEX48+NNH42N+T/ gwjE85oyQ+0lmsraA4hQcsAa/NcMIxK4godOwrLXwzTUSGE2l3p76fKEoCCoHUPw IIRcKulEZ1IeGs7Mj83+zC629qQ37mTfP0OMungIByseykpzlDp3ciw342dk8wk= 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=oYtadS CjJyoj1gc/mqIbbNFo4r2b/oXJmMQQSkip0qfM3ZSdQVPDNMStl0C+rWXQtdPEBa 7/0ARCTbjBz1nGjSqx0GRGFpArQg5Xp6fvGOo6UFIA4DVKCsUnZv5yUphGFPec5n UyjDYza6U+ksH4+khaTR6KcH8Mo9fF7MSa100= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4DDBA8AC21 for ; Mon, 21 Dec 2009 15:56: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 C5EF28AC20 for ; Mon, 21 Dec 2009 15:56:02 -0500 (EST) Message-ID: <4B2FE15B.1050704@pobox.com> Date: Mon, 21 Dec 2009 12:58:03 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> <4B2FB68C.1000400@pobox.com> <4B2FB80E.8080300@extendedsubset.com> In-Reply-To: <4B2FB80E.8080300@extendedsubset.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 402A93CE-EE73-11DE-BC15-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] SCSV vs RI when both specified - consensus? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2009 20:56:21 -0000 Marsh Ray wrote: > > Is everybody OK with this wording? (it's the more lenient choice): > >> Clients MUST NOT put multiple occurrences of an RI extension in the >> same Client Hello message. A client MAY specify the SCSV in the same >> Client Hello message as an RI extension (the SCSV will be effectively >> ignored). >> >> A server receiving a Client Hello containing multiple RI extensions >> MUST generate a fatal "decode_error" alert and terminate the >> connection. A server receiving a Client Hello containing the SCSV >> and an RI extension is to interpret the RI as usual and ignore the >> SCSV. As Nasko pointed out, we don't need to talk about multiple RI extensions. So this could collapse into something like: Clients MAY send SCSV in all ClientHellos, even when also sending an RI extension (either empty or containing data). Servers MUST ignore SCSV when the client has also sent RI. > We'll have to fix the conflict with the current: >> This SCSV is not a true cipher suite and cannot be negotiated. It >> merely has exactly the same semantics as an empty "renegotiation_info" >> extension. > > to something like: >> This SCSV is not a true cipher suite and cannot be negotiated, it >> has similar semantics as an empty "renegotiation_info" extension. Perhaps: This SCSV is not a true cipher suite and cannot be negotiated; a server that encounters SCSV but not RI MUST proceed exactly as if an empty RI extension had been received. Mike From marsh@extendedsubset.com Mon Dec 21 13:20: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 536A53A690B for ; Mon, 21 Dec 2009 13:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu9IQ4-Z+GuX for ; Mon, 21 Dec 2009 13:20: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 6A06F3A68F2 for ; Mon, 21 Dec 2009 13:20:58 -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 1NMpgH-000Dwd-Ri; Mon, 21 Dec 2009 21:20:41 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CAEC4603A; Mon, 21 Dec 2009 21:20: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: U2FsdGVkX18WraS1IRb0P5abXJp03JNRLJtL2uMJ5M0= Message-ID: <4B2FE6AC.6060808@extendedsubset.com> Date: Mon, 21 Dec 2009 15:20:44 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael D'Errico References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> <4B2FB68C.1000400@pobox.com> <4B2FB80E.8080300@extendedsubset.com> <4B2FE15B.1050704@pobox.com> In-Reply-To: <4B2FE15B.1050704@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] SCSV vs RI when both specified - consensus? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2009 21:20:59 -0000 Michael D'Errico wrote: > Marsh Ray wrote: >> > > As Nasko pointed out, we don't need to talk about multiple RI extensions. I think there is a need to reiterate it, at least to the point of spending a sentence or two reminding about it. It sounds like this might be the main RFC some folks will be reading when they go to implement minimal extension handling. Many security bugs exploit the way different system components handle ambiguous situations. For example, if a server interpreted the first RI extension, yet his inspecting firewall interpreted the last one... It's also an easy mistake to make. For example, I don't think the code I posted here a few weeks ago checked for the case. > Perhaps: > > This SCSV is not a true cipher suite and cannot be negotiated; a > server that encounters SCSV but not RI MUST proceed exactly as if > an empty RI extension had been received. I'd prefer not to use the word "exactly" when there are subtle differences (e.g., hash computation). Also, I'm not really sure the behavioral requirement belongs in that section. The first part of the sentence says what SCSV is not, the second says how one endpoint handles one particular possible case. // How about: (with input from MRex) A client MAY specify the SCSV in the same Client Hello message as an RI extension (the SCSV will be effectively ignored). Note that TLS [RFC5246] prohibits clients from putting multiple occurrences of an RI extension in the same Client Hello message. [...] A server receiving a Client Hello containing the SCSV and an RI extension is to interpret the RI as usual and ignore the SCSV. A server receiving a Client Hello containing multiple RI extensions MUST handle it as an error per TLS [RFC5246]. // Change the current: This SCSV is not a true cipher suite and cannot be negotiated. It merely has exactly the same semantics as an empty "renegotiation_info" extension. // to: This SCSV is not a true cipher suite and cannot be negotiated, it has similar semantics as an empty "renegotiation_info" extension. - Marsh From geoffk@geoffk.org Mon Dec 21 14:12: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 1AF993A6ACE for ; Mon, 21 Dec 2009 14:12: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 1Lmoe5QFYs5m for ; Mon, 21 Dec 2009 14:12:03 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 1D60828C0D0 for ; Mon, 21 Dec 2009 14:12:03 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id AFB1333D125; Mon, 21 Dec 2009 22:11:33 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Michael D'Errico References: <200912211949.nBLJn4H8002441@fs4113.wdf.sap.corp> <4B2FDB93.4090105@pobox.com> From: Geoffrey Keating Date: 21 Dec 2009 14:11:33 -0800 In-Reply-To: <4B2FDB93.4090105@pobox.com> Message-ID: Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 21 Dec 2009 14:22:50 -0800 Cc: tls@ietf.org Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 22:13:13 -0000 Michael D'Errico writes: > Martin Rex wrote: > > Marsh Ray wrote: > >> Martin Rex wrote: > >>> Marsh Ray wrote: > >>> > >>>> At the TLS level, it's possible for the current session to be > >>>> anon-anon-DH, which provides no protection. > >>> And which rfc-5246 requires to _not_ request a client certificate: > >>> > >>> 7.4.4. Certificate Request > >>> > >>> When this message will be sent: > >>> > >>> A non-anonymous server can optionally request a certificate from > >>> the client, if appropriate for the selected cipher suite. > >> The client cert is requested in the renegotiating handshake, not the > >> initial one. An anon-anon-DH session provides no "protection" for the > >> client cert passed in renegotiation. > >> > >> But it probably makes some people feel more secure to not see the > >> details (usernames, emails, phone numbers, street addresses) flying by > >> on the wire. > > OK. You are correct. > > That provision in 7.4.4. is about the _current_ handshake only > > and refers to the fact that a server has sent a "Certificate" > > message prior to CertificateRequest. Since at the point of > > the handshake, the Server is _not_ authenticated. There could have > > been a certificate path validation of the server certificate, > > but there is no proof yet, that the alleged server knows the > > necessary private key to the presented certificate, so this > > restriction in 7.4.4. does not provide security. > > If a DHE cipher suite is used, then the server can be authenticated > using only Certificate and ServerKeyExchange. With RSA cipher suites, > you are correct that a client doesn't authenticate the server until > Finished verifies. I think that still doesn't prove that there is no man in the middle. The MITM could forward the ClientHello to the real server, which will return a signed ServerKeyExchange with the correct client_random and server_random. The MITM won't be able to use the associated DH parameters but they aren't necessary until later in the exchange. Even sending the client certificate by renegotiating under an anonymous connection provides protection against any attacker who can see traffic but cannot (or does not want to) perform an active attack. I don't think it's generally useful to do start off anonymous, though, because the server is going to have to provide a certificate later anyway. Another approach, of course, is to not put unnecessary personal information in the client certificate in the first place. From mrex@sap.com Mon Dec 21 14:23: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 18C4428C148 for ; Mon, 21 Dec 2009 14:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 kYkrnc6X22RU for ; Mon, 21 Dec 2009 14:23: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 52A5F3A686C for ; Mon, 21 Dec 2009 14:23:12 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBLMMsSq017506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 23:22:54 +0100 (MET) From: Martin Rex Message-Id: <200912212222.nBLMMs7D011751@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Mon, 21 Dec 2009 23:22:54 +0100 (MET) In-Reply-To: <4B2FDB93.4090105@pobox.com> from "Michael D'Errico" at Dec 21, 9 12:33:23 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] Handshake not under 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, 21 Dec 2009 22:23:14 -0000 Michael D'Errico wrote: > > Martin Rex wrote: > > > > Marsh Ray wrote: > > > > > > The client cert is requested in the renegotiating handshake, not the > > > initial one. An anon-anon-DH session provides no "protection" for the > > > client cert passed in renegotiation. > > > > OK. You are correct. > > > > That provision in 7.4.4. is about the _current_ handshake only > > and refers to the fact that a server has sent a "Certificate" > > message prior to CertificateRequest. Since at the point of > > the handshake, the Server is _not_ authenticated. There could have > > been a certificate path validation of the server certificate, > > but there is no proof yet, that the alleged server knows the > > necessary private key to the presented certificate, so this > > restriction in 7.4.4. does not provide security. > > If a DHE cipher suite is used, then the server can be authenticated > using only Certificate and ServerKeyExchange. With RSA cipher suites, > you are correct that a client doesn't authenticate the server until > Finished verifies. I'm not sure I can follow why you think it is protected. RFC-5246, 7.4.3. Server Key Exchange Message struct { select (KeyExchangeAlgorithm) { case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct { opaque client_random[32]; opaque server_random[32]; ServerDHParams params; } signed_params; case rsa: case dh_dss: case dh_rsa: struct {} ; /* message is omitted for rsa, dh_dss, and dh_rsa */ /* may be extended, e.g., for ECDH -- see [TLSECC] */ }; } ServerKeyExchange; There is signed_params in the Server Key Exchange Message, but it does _not_ seem to protect from MitM (when the attackers objective is to elicit a Certificate message with the client's identity from the attacked client). If an attacker has a rogue server that wants to determine the client's identity, then this attacker could open a connection to the particular server to which it knows the client will reveal his identity, resend the ClientHello just received and obtain a ServerHello and ServerKeyExchange that match and then replay this information to the client (i.e. the server_random used by the real server and the signed_params sent by the real server. -Martin From marsh@extendedsubset.com Mon Dec 21 14: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 851323A697C for ; Mon, 21 Dec 2009 14:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guQg+J3p5Bod for ; Mon, 21 Dec 2009 14:47: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 AD71F3A682C for ; Mon, 21 Dec 2009 14:47: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 1NMr2F-0006Nq-5n; Mon, 21 Dec 2009 22:47:27 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 12F5A603A; Mon, 21 Dec 2009 22:47:25 +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: U2FsdGVkX18ivlOoDHX6M4lzQR2iNHoocC08zgVrBKk= Message-ID: <4B2FFB00.4050505@extendedsubset.com> Date: Mon, 21 Dec 2009 16:47:28 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912212222.nBLMMs7D011751@fs4113.wdf.sap.corp> In-Reply-To: <200912212222.nBLMMs7D011751@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] Handshake not under 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, 21 Dec 2009 22:47:44 -0000 Martin Rex wrote: > Michael D'Errico wrote: >> If a DHE cipher suite is used, then the server can be authenticated >> using only Certificate and ServerKeyExchange. With RSA cipher suites, >> you are correct that a client doesn't authenticate the server until >> Finished verifies. > > I'm not sure I can follow why you think it is protected. > > RFC-5246, 7.4.3. Server Key Exchange Message > > struct { > select (KeyExchangeAlgorithm) { > case dh_anon: > ServerDHParams params; > case dhe_dss: > case dhe_rsa: > ServerDHParams params; > digitally-signed struct { > opaque client_random[32]; > opaque server_random[32]; > ServerDHParams params; > } signed_params; > case rsa: > case dh_dss: > case dh_rsa: > struct {} ; > /* message is omitted for rsa, dh_dss, and dh_rsa */ > /* may be extended, e.g., for ECDH -- see [TLSECC] */ > }; > } ServerKeyExchange; > > There is signed_params in the Server Key Exchange Message, but > it does _not_ seem to protect from MitM (when the attackers objective > is to elicit a Certificate message with the client's identity > from the attacked client). > > If an attacker has a rogue server that wants to determine the client's > identity, then this attacker could open a connection to the particular > server to which it knows the client will reveal his identity, > resend the ClientHello just received and obtain a ServerHello and > ServerKeyExchange that match and then replay this information to > the client (i.e. the server_random used by the real server and > the signed_params sent by the real server. I think you stopped too soon: http://tools.ietf.org/html/rfc4346#page-42 > struct { > select (KeyExchangeAlgorithm) { > case diffie_hellman: > ServerDHParams params; > case rsa: > ServerRSAParams params; > }; > } ServerParams; > > params > The server's key exchange parameters. > > signed_params > For non-anonymous key exchanges, a hash of the corresponding > params value, with the signature appropriate to that hash > applied. > > md5_hash > MD5(ClientHello.random + ServerHello.random + ServerParams); > > sha_hash > SHA(ClientHello.random + ServerHello.random + ServerParams); AFAICT, MitM is forced to pass the same DHE params from the server to the client, else he breaks the signed hash which covers ServerParams. Since he passes the correct DHE params S->C, he cannot intercept the traffic from client to server. - Marsh From mrex@sap.com Mon Dec 21 14:49: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 CBB303A6842 for ; Mon, 21 Dec 2009 14:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 1HSSNie6-aAi for ; Mon, 21 Dec 2009 14:49:16 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B2F8A3A6930 for ; Mon, 21 Dec 2009 14:49:15 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBLMmuBb008245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 23:48:56 +0100 (MET) From: Martin Rex Message-Id: <200912212248.nBLMmtI2013404@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Mon, 21 Dec 2009 23:48:55 +0100 (MET) In-Reply-To: <4B2FCE60.3020507@extendedsubset.com> from "Marsh Ray" at Dec 21, 9 01:37:04 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: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 22:49:16 -0000 There seems to be a slight confusion based on me quoting only part of Marsh' reply, and not the part the confirms the technical possibility of client identity protection (below). I confirmed that the restriction in rfc-5246 7.4.4. Certificate Request "A non-anonymous server can optionally request a certificate from the client" can not protect against server that wants to elicit a "Certificate" message from TLS clients in order to reveal the identity of these clients. > > I have seen common recommendations to have the server ask for it by > renegotiation, as if that were a secure solution. Correct. This will protect client identies only from purely passive observers/attackers. > > > The client certificate itself is sent with whatever protection the > > record layer currently applies (non on an initial handshake) without > > any kind of additional protection in a Certificate message from the client > > to the server if the server includes a CertificateRequest message > > between ServerHello and ServerHelloDone. > > > > At that point, the Server is _not_ authenticated. The server has > > already sent his "Certificate" message (containing the server certificate), > > but that could be fake. Only when the TLS handshake succeeds, the > > client knows that the provided server certificate wasn't fake > > Yep. > > > -- and > > at that point the application could decide whether it wants to > > reveal its identity to that authenticated server through TLS > > renegotiation. > > There are several significant points during the handshake that seem to > require special application-layer processing. Rarely do we see one > callback implemented perfectly, much less for two handshakes! > > > Client identity protection through renegotiation _can_ be used in > > a secure fashion. > > It could be done securely if the application layer specified its > operation thoroughly. > > HTTPS does not, I wonder if any do? > > > There is no guidance in the TLS spec how to do it, > > though, and most existing clients are willing to send a client > > certificate in any handshake. > > That's my point exactly. OK. How about this characterization then: Although it's technically possible to implement client identity protection securely with the existing protocol, it is so significantly underspecified that it makes it unlikely that even those clients which care about this, implement it in a secure fashion today. -Martin From marsh@extendedsubset.com Mon Dec 21 14:57: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 50A483A68B6 for ; Mon, 21 Dec 2009 14:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPyk3KZv4ykA for ; Mon, 21 Dec 2009 14:57:38 -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 946FA3A68EF for ; Mon, 21 Dec 2009 14:57:38 -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 1NMrBq-000NzZ-3P; Mon, 21 Dec 2009 22:57:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1BAA5603A; Mon, 21 Dec 2009 22:57:20 +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: U2FsdGVkX19nX1hof3UIGMV8Sz87waGdIAhi3QFCyrc= Message-ID: <4B2FFD53.2090508@extendedsubset.com> Date: Mon, 21 Dec 2009 16:57:23 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mrex@sap.com References: <200912212248.nBLMmtI2013404@fs4113.wdf.sap.corp> In-Reply-To: <200912212248.nBLMmtI2013404@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: ravi@findravi.com, tls@ietf.org Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 22:57:39 -0000 Martin Rex wrote: > > OK. How about this characterization then: > > Although it's technically possible to implement client identity > protection securely with the existing protocol, it is so significantly > underspecified that it makes it unlikely that even those clients > which care about this, implement it in a secure fashion today. Good. I would just add: A server-only solution may prevent disclosing the client certificate to a passive observer, it will not protect it from an attacker who can act as an active man-in-the-middle for the underlying transport. - Marsh From mike-list@pobox.com Mon Dec 21 15:28: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 811523A687D for ; Mon, 21 Dec 2009 15:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ63CEI2O02L for ; Mon, 21 Dec 2009 15:28:21 -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 7BEBC3A67A1 for ; Mon, 21 Dec 2009 15:28:20 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BAA188A848 for ; Mon, 21 Dec 2009 18: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:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Rz7ExXQY7FUe G/dpytUGDVPBXRY=; b=xuxkI7xNL37i+yL52bDQ0SkiVgZC0Fv0p2ZmwY1AaFDY X8Bj6zNlkOVkKms7CMwaIvxKOZT05o/PO/Ln3oAsqHXIe8vJo9eZ+dZbJzP6JQ68 RGrrfCMPgN0NQKIFBL3TZfkAIUujuOPhozj+uv841Mdq52GSwzenu27LTSdAw40= 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=xSbk+v hCJl+PY/ASWETKLCWO1K1C50lV3gk9na2hgvEm0pZrIPnG2CBfv0nMlCxBIsRFkH ONF9W2ml45A+lYvSo474oesr0nWiH5d/Z4RgtBR/w/k8AA7/THN5D8VLMaTxl3fT 3VoM8Kq/MUV8uj5hRHnmrSCQ46xtiG248n3k4= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B735C8A847 for ; Mon, 21 Dec 2009 18: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 645C58A846 for ; Mon, 21 Dec 2009 18:28:03 -0500 (EST) Message-ID: <4B3004E9.3020702@pobox.com> Date: Mon, 21 Dec 2009 15:29:45 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200912211949.nBLJn4H8002441@fs4113.wdf.sap.corp> <4B2FDB93.4090105@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 7C5E40CE-EE88-11DE-9334-DC0DEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Handshake not under 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, 21 Dec 2009 23:28:22 -0000 Geoffrey Keating wrote: > Michael D'Errico writes: > >> If a DHE cipher suite is used, then the server can be authenticated >> using only Certificate and ServerKeyExchange. With RSA cipher suites, >> you are correct that a client doesn't authenticate the server until >> Finished verifies. > > I think that still doesn't prove that there is no man in the middle. > The MITM could forward the ClientHello to the real server, which will > return a signed ServerKeyExchange with the correct client_random and > server_random. The MITM won't be able to use the associated DH > parameters but they aren't necessary until later in the exchange. Yes, you are right. A MitM can not sign the ServerKeyExchange himself, but he can just ask the real server to do it. But this thread is about sending a client certificate in a renegotiation handshake, so there should be no MitM (if the client has validated the first handshake). Perhaps I misunderstood what was being asked. > Another approach, of course, is to not put unnecessary personal > information in the client certificate in the first place. I have seen someone send a client certificate to my server with a subject that had most attributes containing the string "confidential" and the commonName was basically a unique ID. The only possibly identifying information was the country code, and based on a recent PDF I've read I have a "theory" of who it was! ;-) Mike From mrex@sap.com Mon Dec 21 15:54: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 9BCC13A6A87 for ; Mon, 21 Dec 2009 15:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 lC1CvClnzzyG for ; Mon, 21 Dec 2009 15:54:55 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 74B4A3A6A6E for ; Mon, 21 Dec 2009 15:54:55 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBLNsbVU024051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 00:54:37 +0100 (MET) From: Martin Rex Message-Id: <200912212354.nBLNsbWR017235@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Tue, 22 Dec 2009 00:54:37 +0100 (MET) In-Reply-To: <4B3004E9.3020702@pobox.com> from "Michael D'Errico" at Dec 21, 9 03:29: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] Handshake not under 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, 21 Dec 2009 23:54:56 -0000 Michael D'Errico wrote: > > Yes, you are right. A MitM can not sign the ServerKeyExchange himself, > but he can just ask the real server to do it. > > But this thread is about sending a client certificate in a renegotiation > handshake, so there should be no MitM (if the client has validated the > first handshake). > > Perhaps I misunderstood what was being asked. Since I re-vived this thread, I'll try a summary of the latest messages, which were about availability and security of client identity protection through a TLS renegotiation handshake. When servers do not ask for client certificates on the initial handshake, but only during a TLS renegotiation, then this protectes client identities from passive observers / passive attackers only. If a client wants to protect his identity from active attackers (MitM) as well, and only reveal it to selected servers, then this will require (1) an initial TLS handshake where the TLS server provides his Server certificate (2) an app-level determination that the authenticated TLS-Server to which the client identity may be revealed (3) a TLS renegotiation where the server requests and the client sends a client certificate. A DH_anon session will not be sufficient for (1), because it precludes (2). The authentication of the Server in (3) happens much too late (Server.Finished) to be usable for the determination whether the client may a Certificate message on handshake (3). -Martin From uri@ll.mit.edu Mon Dec 21 20:50: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 3FE583A67A8 for ; Mon, 21 Dec 2009 20:50:26 -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 evkgEaE5Z2Pk for ; Mon, 21 Dec 2009 20:50:25 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 477863A69A0 for ; Mon, 21 Dec 2009 20:50:25 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBM4o7YY017652 for ; Mon, 21 Dec 2009 23:50:07 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAtBaq2F; Mon Dec 21 23:45:10 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Mon, 21 Dec 2009 23:45:10 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Mon, 21 Dec 2009 23:45:10 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqCWqP/QuwhCp6SRzqJOmVfUsOLZQAZubFl Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@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] SCSV vs RI when both specified. Was: Updated 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: Tue, 22 Dec 2009 04:50:26 -0000 SXMgdGhpcyB3aHkgc29sZGllcnMgaW4gdGhlIGZpZWxkIHN3aXRjaCBvZmYgdGhlaXIgYWNjcmVk aXRlZCBjZXJ0aWZpZWQgc2VjdXJlIGNvbW0gZ2VhciAod2hpY2ggd29uJ3QgdGFsayB3aGVuIHRo aW5ncyBsb29rIHRoZSBsZWFzdCBiaXQgZnVubnk/KSBhbmQgdHVybiB0byBjZWxsIHBob25lcz8g QXMgZm9yIHRoZW0gdGhlIG5lZWQgdG8gY29tbXVuaWNhdGUgdXN1YWxseSBkb2VzIE5PVCB0YWtl IGEgYmFjayBzZWF0Lg0KDQpXZSBhcmUgdGFsa2luZyBoeXBvdGhldGljYWxseSBvZiBjb3Vyc2Ug cmF0aGVyIHRoYW4gYWJvdXQgdGhpcyBwYXJ0aWN1bGFyIFRMUyBkZWNpc2lvbiwgd2hpY2ggbWln aHQgd2VsbCBiZSB0aGUgcmlnaHQgY2hvaWNlLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IE1hcnNoIFJheSA8bWFyc2hAZXh0ZW5kZWRzdWJzZXQuY29tPg0KVG86IEJs dW1lbnRoYWwsIFVyaSAtIDA2NjIgLSBNSVRMTA0KQ2M6ICd0bHNAaWV0Zi5vcmcnIDx0bHNAaWV0 Zi5vcmc+DQpTZW50OiBNb24gRGVjIDIxIDExOjI4OjI5IDIwMDkKU3ViamVjdDogUmU6IFtUTFNd IFNDU1YgdnMgUkkgd2hlbiBib3RoIHNwZWNpZmllZC4gV2FzOiBVcGRhdGVkIGRyYWZ0DQoNCkJs dW1lbnRoYWwsIFVyaSAtIDA2NjIgLSBNSVRMTCB3cm90ZToNCj4gVGhlIG9ubHkgcHVycG9zZSBv ZiBhbnkgcHJvdG9jb2wgaXMgdG8gYWxsb3cgZW50aXRpZXMgdG8gY29tbXVuaWNhdGUNCj4gKHVu ZGVyIGEgZ2l2ZW4gc2V0IG9mIGNvbnN0cmFpbnRzKS4gVGh1cyBldmVyeSBlZmZvcnQgU0hPVUxE IGJlDQo+IGludmVzdGVkIHRvIHByb3ZpZGUgdGhpcyBjYXBhYmlsaXR5IHdoZW5ldmVyIHBvc3Np YmxlLg0KDQpUTFMgaXMgYSBjcnlwdG9ncmFwaGljIGRhdGEgc2VjdXJpdHkgcHJvdG9jb2wuDQoN CiJBbGxvd2luZyBlbnRpdGllcyB0byBjb21tdW5pY2F0ZSIgdGFrZXMgYSBiYWNrIHNlYXQgdG8g dGhlIHByaW1hcnkgZ29hbA0Kb2YgcHJldmVudGluZyB1bmF1dGhvcml6ZWQgY29tbXVuaWNhdGlv bi4NCg0KPiBJZiB0aGUNCj4gcHJvdG9jb2wgc3BlYyBkZW1hbmRzIGFib3J0aW5nIGNvbm5lY3Rp b24sIGl0IGJldHRlciBoYXZlIGEgZGFtbiBnb29kDQo+IHJlYXNvbiB0byBkbyBzbyAtIGFuZCBt b3JlIHN1YnN0YW50aXZlIHRoYW4gInNvbWUgU3RldmUgZGVjaWRlZCBpdA0KPiBkb2Vzbid0IHJl YWxseSBtYXR0ZXIgdG8gaGltIGlmIHRoZSBwZWVycyBjb25uZWN0IG9yIG5vdCIuDQoNCkhvdyBh Ym91dCAicmVtb3RlIGVuZHBvaW50IGRvZXNuJ3QgcGFzcyB0aGUgYm96byB0ZXN0Ij8NCg0KPiBQ ZXJzb25hbCBjdXJpb3NpdHkgLSB3aGF0IGtpbmQgb2Ygd29yayBkbyB5b3UgZG8/IChGZWVsIGZy ZWUgdG8NCj4gYW5zd2VyIGluIGEgcHJpdmF0ZSBlbWFpbCBvciB0byBpZ25vcmUgYWx0b2dldGhl ci4pDQoNCkkgZG8gc29mdHdhcmUgZGV2ZWxvcG1lbnQgKGFuZCBzZWN1cml0eSByZXNlYXJjaCkg d29yayBvbiBQaG9uZUZhY3RvciwgYQ0KcHJvZHVjdC9zZXJ2aWNlIGZvciBkb2luZyB0d28tZmFj dG9yIGF1dGhlbnRpY2F0aW9uIHdpdGggb3JkaW5hcnkgcGhvbmVzLg0KDQo+IEknbSBzaG9ja2Vk IHRoYXQgbm9ib2R5IGVsc2Ugc2VlbXMgdG8gcGljayBvbiB0aGlzLiBJcyBpdCB0aGF0DQo+IG1p ZC13ZWVrZW5kIHRoaW5nLCBvciBhbSBJIHRoZSBvbmx5IG9uZSB3aG8gY2FyZXMgd2hldGhlciB0 aGUgcGVlcg0KPiB3b3VsZCBlc3RhYmxpc2ggb3IgcmVmdXNlIGNvbm5lY3Rpb24/IQ0KDQpZZXMs IEkgY2FyZSBncmVhdGx5IHRoYXQgdGhlIHBlZXIgcmVmdXNlcyBhbnkgY29ubmVjdGlvbiB0aGF0 IGxvb2tzIHRoZQ0KbGVhc3QgYml0IGZ1bm55Lg0KDQotIE1hcnNoDQoNCg== From uri@ll.mit.edu Mon Dec 21 20:50: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 E9C083A6AE1 for ; Mon, 21 Dec 2009 20:50:57 -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 LJuptSsODIKw for ; Mon, 21 Dec 2009 20:50:57 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id AD3143A6822 for ; Mon, 21 Dec 2009 20:50:57 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBM4oeBx017874 for ; Mon, 21 Dec 2009 23:50:40 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAtBaq2F; Mon Dec 21 23:45:10 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Mon, 21 Dec 2009 23:45:10 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Mon, 21 Dec 2009 23:45:10 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqCWqP/QuwhCp6SRzqJOmVfUsOLZQAZubFl Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@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] SCSV vs RI when both specified. Was: Updated 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: Tue, 22 Dec 2009 04:50:58 -0000 SXMgdGhpcyB3aHkgc29sZGllcnMgaW4gdGhlIGZpZWxkIHN3aXRjaCBvZmYgdGhlaXIgYWNjcmVk aXRlZCBjZXJ0aWZpZWQgc2VjdXJlIGNvbW0gZ2VhciAod2hpY2ggd29uJ3QgdGFsayB3aGVuIHRo aW5ncyBsb29rIHRoZSBsZWFzdCBiaXQgZnVubnk/KSBhbmQgdHVybiB0byBjZWxsIHBob25lcz8g QXMgZm9yIHRoZW0gdGhlIG5lZWQgdG8gY29tbXVuaWNhdGUgdXN1YWxseSBkb2VzIE5PVCB0YWtl IGEgYmFjayBzZWF0Lg0KDQpXZSBhcmUgdGFsa2luZyBoeXBvdGhldGljYWxseSBvZiBjb3Vyc2Ug cmF0aGVyIHRoYW4gYWJvdXQgdGhpcyBwYXJ0aWN1bGFyIFRMUyBkZWNpc2lvbiwgd2hpY2ggbWln aHQgd2VsbCBiZSB0aGUgcmlnaHQgY2hvaWNlLg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IE1hcnNoIFJheSA8bWFyc2hAZXh0ZW5kZWRzdWJzZXQuY29tPg0KVG86IEJs dW1lbnRoYWwsIFVyaSAtIDA2NjIgLSBNSVRMTA0KQ2M6ICd0bHNAaWV0Zi5vcmcnIDx0bHNAaWV0 Zi5vcmc+DQpTZW50OiBNb24gRGVjIDIxIDExOjI4OjI5IDIwMDkKU3ViamVjdDogUmU6IFtUTFNd IFNDU1YgdnMgUkkgd2hlbiBib3RoIHNwZWNpZmllZC4gV2FzOiBVcGRhdGVkIGRyYWZ0DQoNCkJs dW1lbnRoYWwsIFVyaSAtIDA2NjIgLSBNSVRMTCB3cm90ZToNCj4gVGhlIG9ubHkgcHVycG9zZSBv ZiBhbnkgcHJvdG9jb2wgaXMgdG8gYWxsb3cgZW50aXRpZXMgdG8gY29tbXVuaWNhdGUNCj4gKHVu ZGVyIGEgZ2l2ZW4gc2V0IG9mIGNvbnN0cmFpbnRzKS4gVGh1cyBldmVyeSBlZmZvcnQgU0hPVUxE IGJlDQo+IGludmVzdGVkIHRvIHByb3ZpZGUgdGhpcyBjYXBhYmlsaXR5IHdoZW5ldmVyIHBvc3Np YmxlLg0KDQpUTFMgaXMgYSBjcnlwdG9ncmFwaGljIGRhdGEgc2VjdXJpdHkgcHJvdG9jb2wuDQoN CiJBbGxvd2luZyBlbnRpdGllcyB0byBjb21tdW5pY2F0ZSIgdGFrZXMgYSBiYWNrIHNlYXQgdG8g dGhlIHByaW1hcnkgZ29hbA0Kb2YgcHJldmVudGluZyB1bmF1dGhvcml6ZWQgY29tbXVuaWNhdGlv bi4NCg0KPiBJZiB0aGUNCj4gcHJvdG9jb2wgc3BlYyBkZW1hbmRzIGFib3J0aW5nIGNvbm5lY3Rp b24sIGl0IGJldHRlciBoYXZlIGEgZGFtbiBnb29kDQo+IHJlYXNvbiB0byBkbyBzbyAtIGFuZCBt b3JlIHN1YnN0YW50aXZlIHRoYW4gInNvbWUgU3RldmUgZGVjaWRlZCBpdA0KPiBkb2Vzbid0IHJl YWxseSBtYXR0ZXIgdG8gaGltIGlmIHRoZSBwZWVycyBjb25uZWN0IG9yIG5vdCIuDQoNCkhvdyBh Ym91dCAicmVtb3RlIGVuZHBvaW50IGRvZXNuJ3QgcGFzcyB0aGUgYm96byB0ZXN0Ij8NCg0KPiBQ ZXJzb25hbCBjdXJpb3NpdHkgLSB3aGF0IGtpbmQgb2Ygd29yayBkbyB5b3UgZG8/IChGZWVsIGZy ZWUgdG8NCj4gYW5zd2VyIGluIGEgcHJpdmF0ZSBlbWFpbCBvciB0byBpZ25vcmUgYWx0b2dldGhl ci4pDQoNCkkgZG8gc29mdHdhcmUgZGV2ZWxvcG1lbnQgKGFuZCBzZWN1cml0eSByZXNlYXJjaCkg d29yayBvbiBQaG9uZUZhY3RvciwgYQ0KcHJvZHVjdC9zZXJ2aWNlIGZvciBkb2luZyB0d28tZmFj dG9yIGF1dGhlbnRpY2F0aW9uIHdpdGggb3JkaW5hcnkgcGhvbmVzLg0KDQo+IEknbSBzaG9ja2Vk IHRoYXQgbm9ib2R5IGVsc2Ugc2VlbXMgdG8gcGljayBvbiB0aGlzLiBJcyBpdCB0aGF0DQo+IG1p ZC13ZWVrZW5kIHRoaW5nLCBvciBhbSBJIHRoZSBvbmx5IG9uZSB3aG8gY2FyZXMgd2hldGhlciB0 aGUgcGVlcg0KPiB3b3VsZCBlc3RhYmxpc2ggb3IgcmVmdXNlIGNvbm5lY3Rpb24/IQ0KDQpZZXMs IEkgY2FyZSBncmVhdGx5IHRoYXQgdGhlIHBlZXIgcmVmdXNlcyBhbnkgY29ubmVjdGlvbiB0aGF0 IGxvb2tzIHRoZQ0KbGVhc3QgYml0IGZ1bm55Lg0KDQotIE1hcnNoDQoNCg== From ynir@checkpoint.com Tue Dec 22 00: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 C3ACC3A67CC for ; Tue, 22 Dec 2009 00:22:10 -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 JIzn8sbEko4n for ; Tue, 22 Dec 2009 00:22:10 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C5E0F3A67C0 for ; Tue, 22 Dec 2009 00:22:09 -0800 (PST) X-CheckPoint: {4B308087-10010-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8DC4829C00A; Tue, 22 Dec 2009 10:21:52 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 74C8929C002; Tue, 22 Dec 2009 10:21:52 +0200 (IST) X-CheckPoint: {4B308087-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBM8LqT7009291; Tue, 22 Dec 2009 10:21:52 +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, 22 Dec 2009 10:22:03 +0200 From: Yoav Nir To: Marsh Ray Date: Tue, 22 Dec 2009 10:21:49 +0200 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqC39d3wXNp3wJ5SRKHWJYJyuYCog== Message-ID: References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local> <4B2FA22D.2090800@extendedsubset.com> In-Reply-To: <4B2FA22D.2090800@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] SCSV vs RI when both specified. Was: Updated 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: Tue, 22 Dec 2009 08:22:11 -0000 On Dec 21, 2009, at 6:28 PM, Marsh Ray wrote: > Blumenthal, Uri - 0662 - MITLL wrote: >=20 >> If the >> protocol spec demands aborting connection, it better have a damn good >> reason to do so - and more substantive than "some Steve decided it >> doesn't really matter to him if the peers connect or not". >=20 > How about "remote endpoint doesn't pass the bozo test"? We do not discriminate against bozos. Seriously, servers are there to communicate. Amazon or Google are not going= to turn away customers because their browsers are a little off. That's why= they agree to work in SSLv2.= From ynir@checkpoint.com Tue Dec 22 00: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 7133B3A66B4 for ; Tue, 22 Dec 2009 00:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rne2FNIT2sEr for ; Tue, 22 Dec 2009 00:23:31 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 388303A6883 for ; Tue, 22 Dec 2009 00:23:31 -0800 (PST) X-CheckPoint: {4B3080D9-10007-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8F1A029C00A; Tue, 22 Dec 2009 10:23:14 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 76F4129C002; Tue, 22 Dec 2009 10:23:14 +0200 (IST) X-CheckPoint: {4B3080D9-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBM8NET7009414; Tue, 22 Dec 2009 10:23:14 +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, 22 Dec 2009 10:23:25 +0200 From: Yoav Nir To: Marsh Ray Date: Tue, 22 Dec 2009 10:23:11 +0200 Thread-Topic: [TLS] SCSV vs RI when both specified - consensus? Thread-Index: AcqC4AgqiLk8HGSiSb2nzbh5XY/rgw== Message-ID: References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854018@LLE2K7-BE01.mitll.ad.local> <808FD6E27AD4884E94820BC333B2DB7758409B30F1@NOK-EUMSG-01.mgdnok.nokia.com> <4B2FAAFB.5090908@pobox.com> <4B2FB265.5040203@drh-consultancy.demon.co.uk> <4B2FB68C.1000400@pobox.com> <4B2FB80E.8080300@extendedsubset.com> In-Reply-To: <4B2FB80E.8080300@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] SCSV vs RI when both specified - consensus? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2009 08:23:32 -0000 On Dec 21, 2009, at 8:01 PM, Marsh Ray wrote: > Michael D'Errico wrote: >> I agree we need to publish ASAP, but if consensus is (1), then I need >> to change my (running) code since it currently does (2). >=20 >=20 > Is everybody OK with this wording? (it's the more lenient choice): >=20 >> Clients MUST NOT put multiple occurrences of an RI extension in the >> same Client Hello message. A client MAY specify the SCSV in the same >> Client Hello message as an RI extension (the SCSV will be effectively >> ignored). >>=20 >> A server receiving a Client Hello containing multiple RI extensions >> MUST generate a fatal "decode_error" alert and terminate the >> connection. A server receiving a Client Hello containing the SCSV >> and an RI extension is to interpret the RI as usual and ignore the >> SCSV. I like that (with or without Nasko's suggestion) > We'll have to fix the conflict with the current: >> This SCSV is not a true cipher suite and cannot be negotiated. It >> merely has exactly the same semantics as an empty "renegotiation_info" >> extension. >=20 > to something like: >> This SCSV is not a true cipher suite and cannot be negotiated, it >> has similar semantics as an empty "renegotiation_info" extension. We might want to specify what a client should do if the server chooses the = SCSV cipher suite. Obviously, close the connection, but with what alert?= From rdugal@certicom.com Tue Dec 22 05:10: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 3640C3A68A2 for ; Tue, 22 Dec 2009 05:10:00 -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=[AWL=-0.000, 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 sUik7Enau0Lf for ; Tue, 22 Dec 2009 05:09:59 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 1920E3A6893 for ; Tue, 22 Dec 2009 05:09:59 -0800 (PST) X-AuditID: 0a666446-b7b7dae000004389-a8-4b30c5152c24 Received: from XCH38YKF.rim.net ( [10.64.31.208]) by mhs04ykf.rim.net (RIM Mail) with SMTP id C5.8B.17289.515C03B4; Tue, 22 Dec 2009 08:09:41 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH38YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Dec 2009 08:09:41 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA8308.05F55F8F" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 22 Dec 2009 08:09:41 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402EEF85C@XCH57YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: no_renegotiation alert and SSLV3 Thread-Index: AcqDCAXPVWm6Uw07Qh+UODrxxGmQfg== From: "Robert Dugal" To: X-OriginalArrivalTime: 22 Dec 2009 13:09:41.0363 (UTC) FILETIME=[05CABC30:01CA8308] X-Brightmail-Tracker: AAAAAwAAAZESGuw4EhrsOQ== Subject: [TLS] no_renegotiation alert and 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: Tue, 22 Dec 2009 13:10:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA8308.05F55F8F Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable I am wondering what to do for section 6.2 of draft-ietf-tls-renegotiation-02.txt when SSLv3 is negotiated and RI/SCSV was not in the ClientHello. The no_renegotiation alert was not defined in SSLv3. -- 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_01CA8308.05F55F8F Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

I am wondering what to do for section 6.2 of draft-ietf= -tls-renegotiation-02.txt when SSLv3 is negotiated and RI/SCSV was not in the ClientHello.   = ;

The no_renegotiation alert was not defined in SSLv3.

 

--=

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_01CA8308.05F55F8F-- From mrex@sap.com Tue Dec 22 05:57: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 351153A6835 for ; Tue, 22 Dec 2009 05:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 UKhsH+nf5ulm for ; Tue, 22 Dec 2009 05:57:26 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 37A273A6816 for ; Tue, 22 Dec 2009 05:57:26 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBMDv7Gi016910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 14:57:07 +0100 (MET) From: Martin Rex Message-Id: <200912221357.nBMDv6cb008354@fs4113.wdf.sap.corp> To: rdugal@certicom.com (Robert Dugal) Date: Tue, 22 Dec 2009 14:57:05 +0100 (MET) In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC402EEF85C@XCH57YKF.rim.net> from "Robert Dugal" at Dec 22, 9 08:09: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] no_renegotiation alert and 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: Tue, 22 Dec 2009 13:57:27 -0000 Robert Dugal wrote: > > I am wondering what to do for section 6.2 of > draft-ietf-tls-renegotiation-02.txt when SSLv3 is negotiated and RI/SCSV > was not in the ClientHello. > > The no_renegotiation alert was not defined in SSLv3. If you want to abort the handshake, you could send a fatal handshake alert. I admit to have no relevant implementation experience in that area, but if your objective is to permit the client to continue without renegotiation, I would try the pragmatic approach and send the no_renegotation alert with warning level anyway. This could work at least for those clients that are merely configured to use SSLv3 and not _limited_ to SSLv3. -Martin From mrex@sap.com Tue Dec 22 06:29: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 AF88C3A695E for ; Tue, 22 Dec 2009 06:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 hgG+yLJaJMNA for ; Tue, 22 Dec 2009 06:29:39 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B69C83A680D for ; Tue, 22 Dec 2009 06:29:38 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBMETJ1D029906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 15:29:19 +0100 (MET) From: Martin Rex Message-Id: <200912221429.nBMETIHh010375@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Tue, 22 Dec 2009 15:29:18 +0100 (MET) In-Reply-To: <200912221357.nBMDv6cb008354@fs4113.wdf.sap.corp> from "Martin Rex" at Dec 22, 9 02:57: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: rdugal@certicom.com, tls@ietf.org Subject: Re: [TLS] no_renegotiation alert and 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: Tue, 22 Dec 2009 14:29:39 -0000 Martin Rex wrote: > > Robert Dugal wrote: > > > > I am wondering what to do for section 6.2 of > > draft-ietf-tls-renegotiation-02.txt when SSLv3 is negotiated and RI/SCSV > > was not in the ClientHello. > > > > The no_renegotiation alert was not defined in SSLv3. > > If you want to abort the handshake, you could send a fatal handshake alert. I meant fatal handshake_failure(40) alert. > > I admit to have no relevant implementation experience in that > area, but if your objective is to permit the client to continue > without renegotiation, I would try the pragmatic approach and > send the no_renegotation alert with warning level anyway. > > This could work at least for those clients that are merely configured > to use SSLv3 and not _limited_ to SSLv3. -Martin From marsh@extendedsubset.com Tue Dec 22 08: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 0873C3A6A1B for ; Tue, 22 Dec 2009 08:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMCl83YF8Aoo for ; Tue, 22 Dec 2009 08:40: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 0DF8A3A6A18 for ; Tue, 22 Dec 2009 08:40:44 -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 1NN7me-000NpW-0S; Tue, 22 Dec 2009 16:40:28 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8A7AF603A; Tue, 22 Dec 2009 16:40: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: U2FsdGVkX19PX4Zg7cpMj++UzMhcX8tmvMuSVdEMRyk= Message-ID: <4B30F67D.1030807@extendedsubset.com> Date: Tue, 22 Dec 2009 10:40:29 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Blumenthal, Uri - 0662 - MITLL" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local> 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] SCSV vs RI when both specified. Was: Updated 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: Tue, 22 Dec 2009 16:40:46 -0000 Blumenthal, Uri - 0662 - MITLL wrote: > Is this why soldiers in the field switch off their accredited > certified secure comm gear (which won't talk when things look the > least bit funny?) That's something of a complex question in general. It might be instructive to run down the problems with specific cases though. > and turn to cell phones? As for them the need to > communicate usually does NOT take a back seat. Perhaps the priorities of the soldiers in the field are not in perfect alignment with those who specified the equipment? > We are talking hypothetically of course rather than about this > particular TLS decision, which might well be the right choice. Even when the goal is successful communcation, my experience is the opposite. Paradoxically, it seems that the stricter implementations are expected to be about data they receive, the better they will interoperate in the wild. When receivers are "lenient", senders grow up and get shipped counting on that undocumented behavior. Later receivers come along which are not as lenient, or lenient in different ways, and things break. Compare TLS and HTML: Both were largely driven by Netscape early on. TLS is relatively strict, whereas HTML was intentionally loose. TLS has had a few interop issues, but mainly it's deciding how far back to support old versions. You implementers of course know of some bugs. We've expended a huge amount of effort to work around the few extension-intolerant servers out there, but it sounds like that originated from a document versioning mixup more than anything. HTML, on the other hand, well, it looked to me like Netscape (and later Microsoft) attempted to use its undocumented rendering behavior as some kind of perverse competitive advantage. It was lenient in all sorts of ways and the result is varying degrees of 'quirks mode', which is still with us today. - Marsh > ----- Original Message ----- From: Marsh Ray > To: Blumenthal, Uri - 0662 - MITLL Cc: > 'tls@ietf.org' Sent: Mon Dec 21 11:28:29 2009 Subject: > Re: [TLS] SCSV vs RI when both specified. Was: Updated draft > > Blumenthal, Uri - 0662 - MITLL wrote: >> The only purpose of any protocol is to allow entities to >> communicate (under a given set of constraints). Thus every effort >> SHOULD be invested to provide this capability whenever possible. > > TLS is a cryptographic data security protocol. > > "Allowing entities to communicate" takes a back seat to the primary > goal of preventing unauthorized communication. > >> If the protocol spec demands aborting connection, it better have a >> damn good reason to do so - and more substantive than "some Steve >> decided it doesn't really matter to him if the peers connect or >> not". > > How about "remote endpoint doesn't pass the bozo test"? > >> Personal curiosity - what kind of work do you do? (Feel free to >> answer in a private email or to ignore altogether.) > > I do software development (and security research) work on > PhoneFactor, a product/service for doing two-factor authentication > with ordinary phones. > >> I'm shocked that nobody else seems to pick on this. Is it that >> mid-weekend thing, or am I the only one who cares whether the peer >> would establish or refuse connection?! > > Yes, I care greatly that the peer refuses any connection that looks > the least bit funny. > > - Marsh > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Tue Dec 22 08:51: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 7596D3A68E6 for ; Tue, 22 Dec 2009 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWwxATulJmUP for ; Tue, 22 Dec 2009 08:51:29 -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 9F7B93A6889 for ; Tue, 22 Dec 2009 08:51:29 -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 1NN7x2-000EW7-RS; Tue, 22 Dec 2009 16:51:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F353D603A; Tue, 22 Dec 2009 16:51: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: U2FsdGVkX194045+WZPCAPl/ldnTtk06T3LzTbbmpE8= Message-ID: <4B30F903.8000305@extendedsubset.com> Date: Tue, 22 Dec 2009 10:51:15 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yoav Nir References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local> <4B2FA22D.2090800@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 Cc: "tls@ietf.org" Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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: Tue, 22 Dec 2009 16:51:30 -0000 Yoav Nir wrote: > On Dec 21, 2009, at 6:28 PM, Marsh Ray wrote: > >> Blumenthal, Uri - 0662 - MITLL wrote: >> >>> If the protocol spec demands aborting connection, it better have >>> a damn good reason to do so - and more substantive than "some >>> Steve decided it doesn't really matter to him if the peers >>> connect or not". >> How about "remote endpoint doesn't pass the bozo test"? > > We do not discriminate against bozos. If just one or two of the major implementations did from the beginning, then they wouldn't exist in the ecosystem. > Seriously, servers are there to communicate. Amazon or Google are not > going to turn away customers because their browsers are a little off. > That's why they agree to work in SSLv2. That's their decision, but you cannot let it drive the evolution of the protocol. Some users take security very very seriously. It's common to have a trade-off between security and compatibility. If the protocol spec mandates behavior on the side of security, it remains secure for everyone who needs security. If A&G preferred compatibility they can opt to configure their systems that way. But if the spec sacrifices security for the sake of compatibility, then no one can put the missing security back in later. - Marsh From DPKemp@missi.ncsc.mil Tue Dec 22 09:27: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 C7F353A693E for ; Tue, 22 Dec 2009 09:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.534, 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 cdlSGiUeoE1m for ; Tue, 22 Dec 2009 09:27:38 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id CC8843A6866 for ; Tue, 22 Dec 2009 09:27:37 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 22 Dec 2009 12:19:45 -0500 Message-ID: <200912221727.nBMHRKde023850@stingray.missi.ncsc.mil> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft thread-index: AcqCWqP/QuwhCp6SRzqJOmVfUsOLZQAZubFlABlzwAA= References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local> From: "Kemp, David P." To: X-OriginalArrivalTime: 22 Dec 2009 17:27:44.0812 (UTC) FILETIME=[12A58EC0:01CA832C] Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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: Tue, 22 Dec 2009 17:27:38 -0000 Speaking of the STU-III (which is the latest secure telephone I had a hand in - back in the 1980s), there is a difference between 1) switching off secure mode, and 2) accepting a connection with a bozo peer while perceiving the connection to be secure. Both communicating and accurate security awareness are necessary; those requirements do not conflict. Dave -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Blumenthal, Uri - 0662 - MITLL Sent: Monday, December 21, 2009 11:45 PM To: 'tls@ietf.org' Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft Is this why soldiers in the field switch off their accredited certified secure comm gear (which won't talk when things look the least bit funny?) and turn to cell phones? As for them the need to communicate usually does NOT take a back seat. We are talking hypothetically of course rather than about this particular TLS decision, which might well be the right choice. ----- Original Message ----- From: Marsh Ray To: Blumenthal, Uri - 0662 - MITLL Cc: 'tls@ietf.org' Sent: Mon Dec 21 11:28:29 2009 Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft Blumenthal, Uri - 0662 - MITLL wrote: > The only purpose of any protocol is to allow entities to communicate > (under a given set of constraints). Thus every effort SHOULD be > invested to provide this capability whenever possible. TLS is a cryptographic data security protocol. "Allowing entities to communicate" takes a back seat to the primary goal of preventing unauthorized communication. > If the > protocol spec demands aborting connection, it better have a damn good > reason to do so - and more substantive than "some Steve decided it > doesn't really matter to him if the peers connect or not". How about "remote endpoint doesn't pass the bozo test"? > Personal curiosity - what kind of work do you do? (Feel free to > answer in a private email or to ignore altogether.) I do software development (and security research) work on PhoneFactor, a product/service for doing two-factor authentication with ordinary phones. > I'm shocked that nobody else seems to pick on this. Is it that > mid-weekend thing, or am I the only one who cares whether the peer > would establish or refuse connection?! Yes, I care greatly that the peer refuses any connection that looks the least bit funny. - Marsh _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Pasi.Eronen@nokia.com Tue Dec 22 23:35: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 DB68D3A67A8 for ; Tue, 22 Dec 2009 23:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 atYlayOJWV3r for ; Tue, 22 Dec 2009 23:35:48 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6F89D3A65A6 for ; Tue, 22 Dec 2009 23:35:48 -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 nBN7Z9bb024366; Wed, 23 Dec 2009 09:35:25 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 09:35:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 09:35:08 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 23 Dec 2009 08:35:07 +0100 From: To: , Date: Wed, 23 Dec 2009 08:35:05 +0100 Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: AcqAGzeDAkldwC8qQjWRqwGgxqQqxQAVK08QAMx9ZaA= Message-ID: <808FD6E27AD4884E94820BC333B2DB775840CE3382@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com><6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com> <4B2BDCAC.1040802@bolyard.me> 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: 23 Dec 2009 07:35:08.0471 (UTC) FILETIME=[73D43C70:01CA83A2] X-Nokia-AV: Clean Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2009 07:35:50 -0000 Based on earlier discussions, I don't think we have consensus for this strong change ("SHOULD disable renegotiation by default"). If you ship an updated TLS library with that change, it will break all existing applications that use renegotiation (since they are not aware of the API call to re-enable it, which was probably added in the same update). I think we have rough consensus for "SHOULD have an API to disable/enable renegotiation (depending on which is the default setting)", but not for what the default setting should be. Best regards, Pasi (wearing AD hat) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Joseph Salowey (jsalowey) > Sent: 19 December, 2009 08:03 > To: Nelson B Bolyard; IETF TLS Working Group > Subject: Re: [TLS] Summarizing identity change discussion so far >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > > Behalf Of Nelson B Bolyard > > Sent: Friday, December 18, 2009 11:49 AM > > To: IETF TLS Working Group > > Subject: Re: [TLS] Summarizing identity change discussion so far > > > > On 2009-12-17 23:27 PST, Joseph Salowey (jsalowey) wrote: > > > I share the opinion that identity checking belongs in the > > application, > > > performed according to whatever mechanism is appropriate. > > We should > > > not be mandating any particular PKIX processing in the TLS specs. > > > > > > I also think if an application is not prepared to be aware of > > > renegotiation and handle any identity change associated > > with it then > > > renegotiation should be disabled. This implies that renegotiation > > > should be disabled by default and specifically enabled by an > > > application. So I would say > > > > > > "TLS implementations SHOULD disable renegotiation by > > default and offer > > > the applications the option to enable renegotiation. When an > > > application enables renegotiation it must handle identity > > processing > > > for each handshake." > > > > With my Idealist hat on, I agree with that 100%. But after > > 13.25 years of working on SSL/TLS libraries, I know that 98+% > > of the app developers who use TLS have no idea what that > > means or how to do it. IMO, they are likely to just call a > > function for each handshake that does the same thing as for > > the first handshake, validating the cert chain and (if we're > > lucky) checking that some aspect of the cert contains some > > expected name, without any regard to what prior certificates > > may have contained. > > > > > > So, IMO, it makes sense of TLS implementations to offer some > > sort of "default" handling of certs to attempt to ensure > > continuity of identity in the absence of something much > > better from the application. I'd suggest that, unless the > > applications direct them to do otherwise, perhaps by > > registering some callback, TLS implementations should check > > that the cert in a renegotiation is the same one as in the > > previous full handshake, either by memcmp of the entire cert, > > or by memcmp of the subject name and > > subjectAltName (if any). Anything less will ensure that > > most apps continue > > to get this wrong, IMO. >=20 > [Joe] So ideally renegotiation would be disabled (perhaps after the > client is authenticated in a TLS handshake) unless application enables > it. The TLS implementation can implement some policy on how to match > identity from on handshake to the next, but I'm not confident that any > single specific policy will be the right policy for different > applications and deployments. >=20 > > _______________________________________________ > > 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 cfinss@dial.pipex.com Thu Dec 24 10: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 0172F3A6920 for ; Thu, 24 Dec 2009 10:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL5-rGHYBRCV for ; Thu, 24 Dec 2009 10:42:01 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id A59893A68E6 for ; Thu, 24 Dec 2009 10:42:00 -0800 (PST) X-Trace: 225887954/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.180/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.180 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAJREM0s+vGS0/2dsb2JhbACCXiqFMIhmxEwKgiWCBAQ X-IronPort-AV: E=Sophos;i="4.47,450,1257120000"; d="scan'208";a="225887954" X-IP-Direction: IN Received: from 1cust180.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.180]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Dec 2009 18:41:41 +0000 Message-ID: <044201ca84c0$6dc51420$0601a8c0@allison> From: "tom.petch" To: "Eric Rescorla" , References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> Date: Thu, 24 Dec 2009 18:40:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [TLS] Updated draft - editorial X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 18:42:02 -0000 Eric Some possible clarifications in s.2 (perhaps obvious to those who have read the previous 2,000 posts, but perhaps not to those coming to this afresh) initial intercepted connection initial intercepted TLS connection request (or ClientHello?) He then allows the client's TLS handshake The attacker then allows the client's TLS handshake The handshake is in the clear to the attacker >From the client to the attacker, the handshake is in the clear encrypted over the attacker's TLS connection to the server. encrypted over the attacker's TLS connection to the server, using the security parameters that the attacker has negotiated the client communicates with the server over the newly established the client communicates directly with the server over the newly established the date used in the the data used in the channel binding facility." "channel binding facility". Tom Petch ----- Original Message ----- From: "Eric Rescorla" To: Sent: Wednesday, December 16, 2009 10:32 PM Subject: [TLS] Updated draft > I've just submitted a new draft that is intended to enact most of > Pasi's message as well as the noncontroversial editorial comments > people have raised. Here is what I know still needs work: > > - The final resolution to what's sent in the legacy renegotiation > case (see Pasi's message and the text I sent earlier). > - New text for the identity section in Security considerations. > (Pending closure on the list). > - Make a pass through for clarity for implementors. > (Also, I have some text here that Pasi contributed that I > need to work in). > > If you think you made a comment which is noncontroversial > that didn't make it in and/or I screwed up incorporating your > comment, please let me know and I'll try to fix. > > For some reason, the submission tool is forcing manual > submission. In the interim you can find it at: > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate.txt > > Thanks, > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From cfinss@dial.pipex.com Thu Dec 24 10: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 2E3BD3A695B for ; Thu, 24 Dec 2009 10:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+Zb1AH78Civ for ; Thu, 24 Dec 2009 10:42:02 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id D37933A68F1 for ; Thu, 24 Dec 2009 10:42:01 -0800 (PST) X-Trace: 225887958/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.180/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.180 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAJREM0s+vGS0/2dsb2JhbACCXiqFMIhmxEwKgiWCBAQ X-IronPort-AV: E=Sophos;i="4.47,450,1257120000"; d="scan'208";a="225887958" X-IP-Direction: IN Received: from 1cust180.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.180]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Dec 2009 18:41:43 +0000 Message-ID: <044301ca84c0$6f34d0c0$0601a8c0@allison> From: "tom.petch" To: "Eric Rescorla" , References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> Date: Thu, 24 Dec 2009 18:41:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [TLS] Updated draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 18:42:03 -0000 I find the reference to immediately previous handshake in s.3 unclear. Thinking of session resumption, as identified in RFC5246, there are three cases namely "The session identifier MAY be from an earlier connection, this connection, or from another currently active connection." Which connection should the immediately previous handshake come from given that there may be one session and multiple connections (each of which may be independently re-negotiating) in each of these three cases? My grasp of TLS session and TLS connection may not be as crystal clear as it might be; I see session as defined by a common session identifier but connection being the construct whose protocol is changed by this I-D. Tom Petch ----- Original Message ----- From: "Eric Rescorla" To: Sent: Wednesday, December 16, 2009 10:32 PM Subject: [TLS] Updated draft > I've just submitted a new draft that is intended to enact most of > Pasi's message as well as the noncontroversial editorial comments > people have raised. Here is what I know still needs work: > > - The final resolution to what's sent in the legacy renegotiation > case (see Pasi's message and the text I sent earlier). > - New text for the identity section in Security considerations. > (Pending closure on the list). > - Make a pass through for clarity for implementors. > (Also, I have some text here that Pasi contributed that I > need to work in). > > If you think you made a comment which is noncontroversial > that didn't make it in and/or I screwed up incorporating your > comment, please let me know and I'll try to fix. > > For some reason, the submission tool is forcing manual > submission. In the interim you can find it at: > https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate.txt > > Thanks, > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Thu Dec 24 12:01: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 B95373A689A for ; Thu, 24 Dec 2009 12:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCdQPRmQC6Nt for ; Thu, 24 Dec 2009 12:01: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 DD5E83A69E0 for ; Thu, 24 Dec 2009 12:01:06 -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 1NNtrd-0005id-5O; Thu, 24 Dec 2009 20:00:49 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7CC72603A; Thu, 24 Dec 2009 20:00: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/6T7H/cMJ4H1Xq0lHkI/ccE0Z3Zf9hDRk= Message-ID: <4B33C86D.9010405@extendedsubset.com> Date: Thu, 24 Dec 2009 14:00:45 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tom.petch" References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <044301ca84c0$6f34d0c0$0601a8c0@allison> In-Reply-To: <044301ca84c0$6f34d0c0$0601a8c0@allison> 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] Updated 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, 24 Dec 2009 20:01:11 -0000 tom.petch wrote: > I find the reference to > immediately previous handshake > in s.3 unclear. The complete wording from http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt : > 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. > 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. > Thinking of session resumption, as identified in RFC5246, Please don't. :-) This draft is about renegotiation, session resumption has nothing to do with it. I, too, used to conflate renegotiation and resumption but they are completely unrelated. The term "resumption" only appears in the document twice, both times like "even when TLS session resumption is used". > there are three cases > namely > "The session identifier MAY be from an earlier connection, > this connection, or from another currently active connection." The term "session identifier" appears nowhere in the draft. Session identifiers do not play a part in this fix for renegotiation. > Which connection should the immediately previous handshake come from The connection that is renegotiating. Renegotiation is a change in the session state of a single connection. > given that there may be one session and multiple connections > (each of which may be independently re-negotiating) in each of these three > cases? Sessions don't relate directly to the fix either. The best term I can find for the things that are renegotiated between is "connection state". > My grasp of TLS session and TLS connection may not be as crystal clear > as it might be; This is extremely common, I know it took me weeks to figure it out. Now that I think I understand it, it's no longer obvious to me how why it's so difficult. Improvements in the TLS RFCs might help. Renegotiation is only discussed minimally because it's simple to describe, whereas resumption takes more words. > I see session as defined by a common session > identifier but connection being the construct whose protocol is changed by > this I-D. Looks good to me. Just keep in mind the many-to-many relationship between sessions and connections. A connection may handle multiple sessions (generally at different times) and a session may be on multiple connections (simultaneously or separated in time). An instance of a session on a connection is referred to as a "connection state". - Marsh From nelson@bolyard.me Thu Dec 24 15: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 5E7083A659B for ; Thu, 24 Dec 2009 15:07:52 -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 kYjR3Q01xeOX for ; Thu, 24 Dec 2009 15:07:51 -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 86FAB3A67D9 for ; Thu, 24 Dec 2009 15:07:51 -0800 (PST) Received: (qmail 3482 invoked from network); 24 Dec 2009 23:07:31 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 24 Dec 2009 23:07:30 -0000 Message-ID: <4B33F445.4010203@bolyard.me> Date: Thu, 24 Dec 2009 15:07:49 -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] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Dec 2009 23:07:52 -0000 In a posting in another thread today, Marsh Ray wrote: > Just keep in mind the many-to-many relationship between sessions and > connections. A connection may handle multiple sessions (generally at > different times) and a session may be on multiple connections > (simultaneously or separated in time). An instance of a session on a > connection is referred to as a "connection state". It's also the thing to which a "TLS channel binding" binds, is it not? Believing that it is, I propose that we name it a "TLS channel". Does that proposal cause anyone here any great pain? From mike-list@pobox.com Thu Dec 24 15:20: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 673573A6850 for ; Thu, 24 Dec 2009 15:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGI7Gvyi+rV3 for ; Thu, 24 Dec 2009 15:20:37 -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 5AED63A6820 for ; Thu, 24 Dec 2009 15:20:37 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 83359A92D9 for ; Thu, 24 Dec 2009 18:20:15 -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=mILpyIvTvhVD ezW4VMa+BaZDfcs=; b=rvbZdNggAwEI0omTqgX5Dytd1CBZ2kcgVWNeIGzyh3jD cAZwc1lI/6vu8W1i0AeaTHQZeD2iOkIAzS+J56UV64dENMvxj/R3YwkugaeUnN6x Ka3+m4SSJBbIV6gd6miVqcJNE66ocbBpdwD3uDIWNAtMTCviHg5gIIhFLyvFz7w= 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=rNvjry M20OU0HkFsD8PsGOkGrBusEl1HP0XwFUHmgLUbGUNiQ6AnmikGrwqfEg//0iM0nx ueHBzHLSnplGt/ao11UzTRmUENTz8KhWrZGFw4Bjyur63J4vDM/6kJDpdAbHq2tQ htciKlmpqjNcagmgYFmWtYcOWaotTPga/9JpQ= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7F2C7A92D8 for ; Thu, 24 Dec 2009 18:20:15 -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 9F200A92D6 for ; Thu, 24 Dec 2009 18:20:11 -0500 (EST) Message-ID: <4B33F7B4.3000101@pobox.com> Date: Thu, 24 Dec 2009 15:22:28 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: IETF TLS Working Group References: <4B33F445.4010203@bolyard.me> In-Reply-To: <4B33F445.4010203@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E483B13C-F0E2-11DE-A009-465EBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Dec 2009 23:25:52 -0000 Nelson B Bolyard wrote: > In a posting in another thread today, Marsh Ray wrote: > >> Just keep in mind the many-to-many relationship between sessions and >> connections. A connection may handle multiple sessions (generally at >> different times) and a session may be on multiple connections >> (simultaneously or separated in time). An instance of a session on a >> connection is referred to as a "connection state". > > It's also the thing to which a "TLS channel binding" binds, is it not? > > Believing that it is, I propose that we name it a "TLS channel". > > Does that proposal cause anyone here any great pain? No pain, but I'd like some clarification. I assume that if you make an initial connection to a server and perform a full handshake, you have created a new, independent TLS channel. But now if you make another TCP connection to the same server and resume that session, has a new TLS channel been created? Or is it the same one? Also, let's say you just connected and performed a full handshake, creating a new TLS channel. If you then renegotiate with the server using a full handshake, has a new TLS channel been created? Or is it the same? If you connect, full handshake, and then renegotiate using an old session (session resume), has a new TLS channel been created? Does it depend on whether the resumed session was the original session on this connection? What if a session from an unrelated connection was resumed? Thanks for any insight. Mike From marsh@extendedsubset.com Thu Dec 24 15:32: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 1BB0C3A6811 for ; Thu, 24 Dec 2009 15:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4Qwp4H2FghN for ; Thu, 24 Dec 2009 15:32: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 5FEEB3A659B for ; Thu, 24 Dec 2009 15:32: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 1NNxAC-0007HN-Jh; Thu, 24 Dec 2009 23:32:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 86BE7603A; Thu, 24 Dec 2009 23:32: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/TZIFPhokdyBzWcE9NxvfOrudFQD0uV6c= Message-ID: <4B33F9F9.7040403@extendedsubset.com> Date: Thu, 24 Dec 2009 17:32:09 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nelson B Bolyard References: <4B33F445.4010203@bolyard.me> In-Reply-To: <4B33F445.4010203@bolyard.me> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF TLS Working Group Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 24 Dec 2009 23:32:31 -0000 Merry Chrismas, all. Nelson B Bolyard wrote: > > It's also the thing to which a "TLS channel binding" binds, is it not? > > Believing that it is, I propose that we name it a "TLS channel". /me winces > Does that proposal cause anyone here any great pain? To me, the term 'channel' seems to be heavily overloaded and it comes with a nonzero amount of baggage from the channel binding work. It doesn't "speak to me" as a precise thing the way (for example) "connection state" does. It sounds like a term which people will place their own meaning on and feel like they understand it, and other people will do the same with slightly different meanings. That said, I don't really have a better suggestion right now. - Marsh From nelson@bolyard.me Thu Dec 24 16:23: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 BE2253A694A for ; Thu, 24 Dec 2009 16:23:36 -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 Tkp16vUTWLXY for ; Thu, 24 Dec 2009 16:23:35 -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 80F2F3A67E3 for ; Thu, 24 Dec 2009 16:23:35 -0800 (PST) Received: (qmail 6163 invoked from network); 25 Dec 2009 00:23:17 -0000 Received: from unknown (24.5.142.42) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 25 Dec 2009 00:23:16 -0000 Message-ID: <4B340609.9090008@bolyard.me> Date: Thu, 24 Dec 2009 16:23: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: IETF TLS Working Group References: <4B33F445.4010203@bolyard.me> <4B33F7B4.3000101@pobox.com> In-Reply-To: <4B33F7B4.3000101@pobox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 25 Dec 2009 00:23:36 -0000 On 2009-12-24 15:22 PST, Michael D'Errico wrote: > Nelson B Bolyard wrote: >> In a posting in another thread today, Marsh Ray wrote: >> >>> Just keep in mind the many-to-many relationship between sessions and >>> connections. A connection may handle multiple sessions (generally at >>> different times) and a session may be on multiple connections >>> (simultaneously or separated in time). An instance of a session on a >>> connection is referred to as a "connection state". >> It's also the thing to which a "TLS channel binding" binds, is it not? >> >> Believing that it is, I propose that we name it a "TLS channel". >> >> Does that proposal cause anyone here any great pain? > > No pain, but I'd like some clarification. > > I assume that if you make an initial connection to a server and perform > a full handshake, you have created a new, independent TLS channel. > > But now if you make another TCP connection to the same server and resume > that session, has a new TLS channel been created? Or is it the same one? > > Also, let's say you just connected and performed a full handshake, > creating a new TLS channel. If you then renegotiate with the server > using a full handshake, has a new TLS channel been created? Or is it > the same? > > If you connect, full handshake, and then renegotiate using an old session > (session resume), has a new TLS channel been created? Does it depend on > whether the resumed session was the original session on this connection? > What if a session from an unrelated connection was resumed? > > Thanks for any insight. The "thing" on which I wanted to hang the name "TLS channel" is (in some sense) defined by a cipher and a MAC and a pair of cipher keys and MAC keys. It is uniquely identified (IINM) by the contents of a pair of TLS Finished messages, which is probably why the TLS channel binding proposal wants to use the contents of the pair of TLS Finished messages as its identifier (IINM). Every handshake creates a new one, regardless of whether the handshake is an initial negotiation or a renegotiation, and regardless of whether it does a full or abbreviated handshake (assuming that the client and server do not reuse their "client random" and "server random" values, of course). I believe this is the thing to which Marsh was referring in his comment which I quoted in my original posting. Marsh, please let us know if it is not. (Oh, and winces duly noted. ) From marsh@extendedsubset.com Thu Dec 24 16:46: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 32EB83A677D for ; Thu, 24 Dec 2009 16:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70DbHZHNmJeH for ; Thu, 24 Dec 2009 16:46:27 -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 688A43A659B for ; Thu, 24 Dec 2009 16:46:27 -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 1NNyJl-000Odd-JY; Fri, 25 Dec 2009 00:46:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DA423603A; Fri, 25 Dec 2009 00:46: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: U2FsdGVkX18c2erM2KI8FsXCZAgpsxOS/Z5fERfhquk= Message-ID: <4B340B4D.8030003@extendedsubset.com> Date: Thu, 24 Dec 2009 18:46:05 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nelson B Bolyard References: <4B33F445.4010203@bolyard.me> <4B33F7B4.3000101@pobox.com> <4B340609.9090008@bolyard.me> In-Reply-To: <4B340609.9090008@bolyard.me> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF TLS Working Group Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 25 Dec 2009 00:46:28 -0000 Nelson B Bolyard wrote: > > The "thing" on which I wanted to hang the name "TLS channel" is (in some > sense) defined by a cipher and a MAC and a pair of cipher keys and MAC > keys. It is uniquely identified (IINM) by the contents of a pair of TLS > Finished messages, Yeah, that. > which is probably why the TLS channel binding proposal > wants to use the contents of the pair of TLS Finished messages as its > identifier (IINM). Last I read it, the channel bindings proposal considered the "channel" to be identified by just the first pair of finished messages on the connection and it held constant across subsequent renegotiations. > Every handshake creates a new one, regardless of whether the handshake is > an initial negotiation or a renegotiation, and regardless of whether it > does a full or abbreviated handshake (assuming that the client and server > do not reuse their "client random" and "server random" values, of course). Now that wouldn't be very random of them. > I believe this is the thing to which Marsh was referring in his comment > which I quoted in my original posting. Marsh, please let us know if it > is not. OK then, I won't let you know that I think it is. > (Oh, and winces duly noted. ) - Marsh From uri@ll.mit.edu Sun Dec 27 18:32: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 DF4F53A677D for ; Sun, 27 Dec 2009 18:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 nzmusfVhSp5f for ; Sun, 27 Dec 2009 18:32:24 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 1424A3A6893 for ; Sun, 27 Dec 2009 18:32:23 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBS2W4Kl025274 for ; Sun, 27 Dec 2009 21:32:04 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAnkaatW; Sun Dec 27 21:30:30 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Sun, 27 Dec 2009 21:30:30 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'tls@ietf.org'" Date: Sun, 27 Dec 2009 21:30:28 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqDJZdeiU8ZVmyRRBi4ifP4eX/QZgEQCCHq Message-ID: In-Reply-To: <4B30F67D.1030807@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] SCSV vs RI when both specified. Was: Updated 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, 28 Dec 2009 02:32:25 -0000 On 12/22/09 11:40 , "Marsh Ray" wrote: > Blumenthal, Uri - 0662 - MITLL wrote: >> ................[switch off non-working gear that >> won't talk when things look the least bit funny] >> and turn to cell phones? As for them the need to >> communicate usually does NOT take a back seat. >=20 > Perhaps the priorities of the soldiers in the field are not in perfect > alignment with those who specified the equipment? Exactly. You may add "and there's an experience/understanding gap between those who design systems & write policies vs. those who are supposed to use them in the field to accomplish something meaningful within the situation-given time constraints". --=20 Regards, Uri From benl@google.com Mon Dec 28 05: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 D9BB43A67A2 for ; Mon, 28 Dec 2009 05:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.793 X-Spam-Level: X-Spam-Status: No, score=-105.793 tagged_above=-999 required=5 tests=[AWL=0.183, 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 lpjaoOejvdAh for ; Mon, 28 Dec 2009 05:37:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 6A2FE3A65A6 for ; Mon, 28 Dec 2009 05:37:02 -0800 (PST) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id nBSDagpe021669 for ; Mon, 28 Dec 2009 13:36:42 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1262007402; bh=y07hJKJ4aGV56ipiHYDzgIjEK/0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=WqjUOBoIxMjN7JWbRA61P/E380j1TZmUoNR5Z3EvskBI1iaPot0OAnwGFPKkdZi94 TqaJy6XbOO80d4DshsRaw== 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=DpWeDdPnph/1yJm5vlYV/GU1Rd37V0W1PDGmSDyp/kbQkScUEVtYNeU/YbSvXpXhC Ul8lyYKdu1jsVEtnsw7qg== Received: from qyk37 (qyk37.prod.google.com [10.241.83.165]) by spaceape7.eur.corp.google.com with ESMTP id nBSDadp2005225 for ; Mon, 28 Dec 2009 05:36:41 -0800 Received: by qyk37 with SMTP id 37so4129273qyk.18 for ; Mon, 28 Dec 2009 05:36:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.111.143 with SMTP id s15mr6533725qcp.23.1262007399034; Mon, 28 Dec 2009 05:36:39 -0800 (PST) In-Reply-To: References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local> <4B2FA22D.2090800@extendedsubset.com> Date: Mon, 28 Dec 2009 13:36:36 +0000 Message-ID: <1b587cab0912280536u2fbfaa6eo1f1c28b3c3c6da05@mail.gmail.com> From: Ben Laurie To: Yoav Nir Content-Type: multipart/alternative; boundary=0023544715ecb941f6047bc9feb1 X-System-Of-Record: true Cc: "tls@ietf.org" Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 28 Dec 2009 13:37:04 -0000 --0023544715ecb941f6047bc9feb1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 22, 2009 at 8:21 AM, Yoav Nir wrote: > > On Dec 21, 2009, at 6:28 PM, Marsh Ray wrote: > > > Blumenthal, Uri - 0662 - MITLL wrote: > > > >> If the > >> protocol spec demands aborting connection, it better have a damn good > >> reason to do so - and more substantive than "some Steve decided it > >> doesn't really matter to him if the peers connect or not". > > > > How about "remote endpoint doesn't pass the bozo test"? > > We do not discriminate against bozos. > > Seriously, servers are there to communicate. Amazon or Google are not going > to turn away customers because their browsers are a little off. That's why > they agree to work in SSLv2. > Oh yes we are :-) $ openssl s_client -ssl2 -connect www.google.com:443 CONNECTED(00000003) write:errno=54 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0023544715ecb941f6047bc9feb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 22, 2009 at 8:21 AM, Yoav Ni= r <ynir@checkpo= int.com> wrote:

On Dec 21, 2009, at 6:28 PM, Marsh Ray wrote:

> Blumenthal, Uri - 0662 - MITLL wrote:
>
>> If the
>> protocol spec demands aborting connection, it better have a damn g= ood
>> reason to do so - and more substantive than "some Steve decid= ed it
>> doesn't really matter to him if the peers connect or not"= .
>
> How about "remote endpoint doesn't pass the bozo test"?<= br>
We do not discriminate against bozos.

Seriously, servers are there to communicate. Amazon or Google are not going= to turn away customers because their browsers are a little off. That's= why they agree to work in SSLv2.

Oh yes we are :-)=A0

$ openssl s_client -ssl2 -con= nect www.google.com:443
CONNECTED(00000003)
write:errno=3D54
=A0
_________________________________________= ______
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--0023544715ecb941f6047bc9feb1-- From jsalowey@cisco.com Mon Dec 28 14: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 190553A687C for ; Mon, 28 Dec 2009 14:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 PzWfb7L4-9TE for ; Mon, 28 Dec 2009 14:21:00 -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 EC4DD3A6848 for ; Mon, 28 Dec 2009 14:20: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: ApoEAFi+OEurR7H+/2dsb2JhbAC/R5Rygi+CBAQ X-IronPort-AV: E=Sophos;i="4.47,464,1257120000"; d="scan'208";a="457847723" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 28 Dec 2009 22:20:41 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nBSMKf18024330; Mon, 28 Dec 2009 22:20:41 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); Mon, 28 Dec 2009 14:20:41 -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: Mon, 28 Dec 2009 14:20:39 -0800 Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775840CE3382@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Summarizing identity change discussion so far Thread-Index: AcqAGzeDAkldwC8qQjWRqwGgxqQqxQAVK08QAMx9ZaABD/G1kA== References: <808FD6E27AD4884E94820BC333B2DB774F31A4FD08@NOK-EUMSG-01.mgdnok.nokia.com><6b9359640912171337j7ed5be63gf431e0fb12070944@mail.gmail.com><808FD6E27AD4884E94820BC333B2DB774F31F77BDC@NOK-EUMSG-01.mgdnok.nokia.com><4B2BDCAC.1040802@bolyard.me> <808FD6E27AD4884E94820BC333B2DB775840CE3382@NOK-EUMSG-01.mgdnok.nokia.com> From: "Joseph Salowey (jsalowey)" To: , X-OriginalArrivalTime: 28 Dec 2009 22:20:41.0017 (UTC) FILETIME=[FD5C1A90:01CA880B] Subject: Re: [TLS] Summarizing identity change discussion so far X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2009 22:21:04 -0000 =20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Tuesday, December 22, 2009 11:35 PM > To: Joseph Salowey (jsalowey); tls@ietf.org > Subject: RE: [TLS] Summarizing identity change discussion so far >=20 > Based on earlier discussions, I don't think we have consensus=20 > for this strong change ("SHOULD disable renegotiation by=20 > default"). If you ship an updated TLS library with that=20 > change, it will break all existing applications that use=20 > renegotiation (since they are not aware of the API call to=20 > re-enable it, which was probably added in the same update). >=20 [Joe] I agree.=20 > I think we have rough consensus for "SHOULD have an API to=20 > disable/enable renegotiation (depending on which is the=20 > default setting)", but not for what the default setting should be. >=20 [Joe] I'm OK with text along those lines. How about replacing the 3rd paragraph with: "TLS implementations SHOULD provide a mechanism to disable and enable renegotiation. " I would also favor adding something like the following to the 5th paragraph, but I could live without it: "To make life simpler for applications that do not expect the certificate to change once it's been authenticated, TLS implementations may also wish to offer the applications the option abort the renegotiation if the peer tries to authenticate with a different certificate and/or different server name (in the server_name extension) than was used earlier. TLS implementations may alternatively offer the option to disable renegotiation once the client certificate has be authenticated. However, enabling these options by default for all applications could break existing applications that depend on using renegotiation to change from one certificate to another. (For example, long-lived TLS connections could change to a renewed certificate; or renegotiation could select a different cipher suite that requires using a different certificate.) > Best regards, > Pasi > (wearing AD hat) >=20 > > -----Original Message----- > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of=20 > > ext Joseph Salowey (jsalowey) > > Sent: 19 December, 2009 08:03 > > To: Nelson B Bolyard; IETF TLS Working Group > > Subject: Re: [TLS] Summarizing identity change discussion so far > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org]=20 > On Behalf=20 > > > Of Nelson B Bolyard > > > Sent: Friday, December 18, 2009 11:49 AM > > > To: IETF TLS Working Group > > > Subject: Re: [TLS] Summarizing identity change discussion so far > > > > > > On 2009-12-17 23:27 PST, Joseph Salowey (jsalowey) wrote: > > > > I share the opinion that identity checking belongs in the > > > application, > > > > performed according to whatever mechanism is appropriate. > > > We should > > > > not be mandating any particular PKIX processing in the=20 > TLS specs. > > > > > > > > I also think if an application is not prepared to be aware of=20 > > > > renegotiation and handle any identity change associated > > > with it then > > > > renegotiation should be disabled. This implies that=20 > renegotiation=20 > > > > should be disabled by default and specifically enabled by an=20 > > > > application. So I would say > > > > > > > > "TLS implementations SHOULD disable renegotiation by > > > default and offer > > > > the applications the option to enable renegotiation. When an=20 > > > > application enables renegotiation it must handle identity > > > processing > > > > for each handshake." > > > > > > With my Idealist hat on, I agree with that 100%. But after > > > 13.25 years of working on SSL/TLS libraries, I know that=20 > 98+% of the=20 > > > app developers who use TLS have no idea what that means=20 > or how to do=20 > > > it. IMO, they are likely to just call a function for=20 > each handshake=20 > > > that does the same thing as for the first handshake,=20 > validating the=20 > > > cert chain and (if we're > > > lucky) checking that some aspect of the cert contains=20 > some expected=20 > > > name, without any regard to what prior certificates may have=20 > > > contained. > > > > > > > > > So, IMO, it makes sense of TLS implementations to offer=20 > some sort of=20 > > > "default" handling of certs to attempt to ensure continuity of=20 > > > identity in the absence of something much better from the=20 > > > application. I'd suggest that, unless the applications=20 > direct them=20 > > > to do otherwise, perhaps by registering some callback, TLS=20 > > > implementations should check that the cert in a=20 > renegotiation is the=20 > > > same one as in the previous full handshake, either by=20 > memcmp of the=20 > > > entire cert, or by memcmp of the subject name and > > > subjectAltName (if any). Anything less will ensure that > > > most apps continue > > > to get this wrong, IMO. > >=20 > > [Joe] So ideally renegotiation would be disabled (perhaps after the=20 > > client is authenticated in a TLS handshake) unless=20 > application enables > > it. The TLS implementation can implement some policy on=20 > how to match > > identity from on handshake to the next, but I'm not=20 > confident that any=20 > > single specific policy will be the right policy for different=20 > > applications and deployments. > >=20 > > > _______________________________________________ > > > 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 >=20 From cfinss@dial.pipex.com Tue Dec 29 09:13: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 B05F23A6933 for ; Tue, 29 Dec 2009 09:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_40=-0.185, J_CHICKENPOX_35=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 uSUlo1YCUCuO for ; Tue, 29 Dec 2009 09:13:42 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 6E10C3A683D for ; Tue, 29 Dec 2009 09:13:42 -0800 (PST) X-Trace: 226420938/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.118/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.118 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAPXGOUs+vGl2/2dsb2JhbACCWyqFL4g/xgoKhCcE X-IronPort-AV: E=Sophos;i="4.47,469,1257120000"; d="scan'208";a="226420938" X-IP-Direction: IN Received: from 1cust118.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.118]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Dec 2009 17:13:18 +0000 Message-ID: <051a01ca88a1$e5da94a0$0601a8c0@allison> From: "tom.petch" To: "Marsh Ray" References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <044301ca84c0$6f34d0c0$0601a8c0@allison> <4B33C86D.9010405@extendedsubset.com> Date: Tue, 29 Dec 2009 17:10:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: tls@ietf.org Subject: Re: [TLS] Updated draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 17:13:44 -0000 ----- Original Message ----- From: "Marsh Ray" Sent: Thursday, December 24, 2009 9:00 PM > tom.petch wrote: > > I find the reference to > > immediately previous handshake > > in s.3 unclear. > > The complete wording from > http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt : > > 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. > > 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. > > > Thinking of session resumption, as identified in RFC5246, > > Please don't. :-) > > This draft is about renegotiation, session resumption has nothing to do > with it. > > I, too, used to conflate renegotiation and resumption but they are > completely unrelated. > > The term "resumption" only appears in the document twice, both times > like "even when TLS session resumption is used". > > > there are three cases > > namely > > "The session identifier MAY be from an earlier connection, > > this connection, or from another currently active connection." > > The term "session identifier" appears nowhere in the draft. Session > identifiers do not play a part in this fix for renegotiation. Marsh This quote is from the base document for which this I-D is a corrigendum, so unless the I-D amends it, the quote still applies. This I-D should make clear the interaction of 'immediately previous handshake' with respect to sessions and connections and at present, I don't think it does so. It is unfortunate that neither sessions nor connections nor renegotiation (nor things:-) are clearly defined so I will see what emerges from the parallel thread on things and then most likely raise this again Tom Petch. > > Which connection should the immediately previous handshake come from > > The connection that is renegotiating. > > Renegotiation is a change in the session state of a single connection. > > > given that there may be one session and multiple connections > > (each of which may be independently re-negotiating) in each of these three > > cases? > > Sessions don't relate directly to the fix either. The best term I can > find for the things that are renegotiated between is "connection state". > > > My grasp of TLS session and TLS connection may not be as crystal clear > > as it might be; > > This is extremely common, I know it took me weeks to figure it out. Now > that I think I understand it, it's no longer obvious to me how why it's > so difficult. > > Improvements in the TLS RFCs might help. Renegotiation is only discussed > minimally because it's simple to describe, whereas resumption takes more > words. > > > I see session as defined by a common session > > identifier but connection being the construct whose protocol is changed by > > this I-D. > > Looks good to me. > > Just keep in mind the many-to-many relationship between sessions and > connections. A connection may handle multiple sessions (generally at > different times) and a session may be on multiple connections > (simultaneously or separated in time). An instance of a session on a > connection is referred to as a "connection state". > > - Marsh > From cfinss@dial.pipex.com Tue Dec 29 09:13: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 488D23A694E for ; Tue, 29 Dec 2009 09:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-0.838, 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 rCNbJ3xgdVov for ; Tue, 29 Dec 2009 09:13:43 -0800 (PST) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 200663A68CF for ; Tue, 29 Dec 2009 09:13:42 -0800 (PST) X-Trace: 226420940/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.118/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.118 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAPXGOUs+vGl2/2dsb2JhbACCWyqFL4g/xgoKhCcE X-IronPort-AV: E=Sophos;i="4.47,469,1257120000"; d="scan'208";a="226420940" X-IP-Direction: IN Received: from 1cust118.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.118]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Dec 2009 17:13:21 +0000 Message-ID: <051b01ca88a1$e6bc6920$0601a8c0@allison> From: "tom.petch" To: "Nelson B Bolyard" , "IETF TLS Working Group" References: <4B33F445.4010203@bolyard.me> <4B33F7B4.3000101@pobox.com> <4B340609.9090008@bolyard.me> Date: Tue, 29 Dec 2009 17:13:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 17:13:44 -0000 ----- Original Message ----- From: "Nelson B Bolyard" Sent: Friday, December 25, 2009 1:23 AM > On 2009-12-24 15:22 PST, Michael D'Errico wrote: > > Nelson B Bolyard wrote: > >> In a posting in another thread today, Marsh Ray wrote: > >> > >>> Just keep in mind the many-to-many relationship between sessions and > >>> connections. A connection may handle multiple sessions (generally at > >>> different times) and a session may be on multiple connections > >>> (simultaneously or separated in time). An instance of a session on a > >>> connection is referred to as a "connection state". > >> It's also the thing to which a "TLS channel binding" binds, is it not? > >> > >> Believing that it is, I propose that we name it a "TLS channel". > >> > >> Does that proposal cause anyone here any great pain? > > > > No pain, but I'd like some clarification. > > > > I assume that if you make an initial connection to a server and perform > > a full handshake, you have created a new, independent TLS channel. > > > > But now if you make another TCP connection to the same server and resume > > that session, has a new TLS channel been created? Or is it the same one? > > > > Also, let's say you just connected and performed a full handshake, > > creating a new TLS channel. If you then renegotiate with the server > > using a full handshake, has a new TLS channel been created? Or is it > > the same? > > > > If you connect, full handshake, and then renegotiate using an old session > > (session resume), has a new TLS channel been created? Does it depend on > > whether the resumed session was the original session on this connection? > > What if a session from an unrelated connection was resumed? > > > > Thanks for any insight. > > The "thing" on which I wanted to hang the name "TLS channel" is (in some > sense) defined by a cipher and a MAC and a pair of cipher keys and MAC > keys. It is uniquely identified (IINM) by the contents of a pair of TLS > Finished messages, which is probably why the TLS channel binding proposal > wants to use the contents of the pair of TLS Finished messages as its > identifier (IINM). I think that nailing a term to this concept is an excellent idea. As Marsh just said, and Nico amplified on 7Dec09, channel bindings refers to the first such thing as long as subsequent renegotiations are bound to the first (which the fixes under discussion would do); if they are not bound, then each handshake would generate a new secure channel with its own bindings which makes the use of 'channel' for 'thing' a bit flaky. Back on 2Nov09, Nico seemed to refer to this thing as a TLS connection (and cited Larry as using the term security context for the same concept). But then, on 2Dec09, Eric agreed that TLS connection and TCP connection were one-to-one which, since renegotiation can occur within a TCP connection, would rule out TLS connection for this thing. Plenty of synonyms in Roget (vide 'junction') but I would go for (TLS|security) context. Tom Petch > Every handshake creates a new one, regardless of whether the handshake is > an initial negotiation or a renegotiation, and regardless of whether it > does a full or abbreviated handshake (assuming that the client and server > do not reuse their "client random" and "server random" values, of course). > > I believe this is the thing to which Marsh was referring in his comment > which I quoted in my original posting. Marsh, please let us know if it > is not. (Oh, and winces duly noted. ) From mike-list@pobox.com Tue Dec 29 10: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 8C1D13A695C for ; Tue, 29 Dec 2009 10:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r85YfeOxJ11L for ; Tue, 29 Dec 2009 10:31: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 83D5F3A6907 for ; Tue, 29 Dec 2009 10:31: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 6856C8CBA1 for ; Tue, 29 Dec 2009 13:30: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=doPekX4xjcvl OvlEdaFbsWh8Hns=; b=fA0WfxGBXS8YJv7qCdyEoxf5RvxMvbporb1uEIKvlJox tUT6kUvO37yFF6HGHBpQHuGd9YGKnkUV02fh6kGwVtKEv9PJKzuauoNDe811U8lp C0n+rsr6wqrOxmynWRyThaLM0cQlx2AaCllGHLJpNkWV+f6E9NiuVnEFjxyXezE= 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=Phr8H4 d3X6bj/HlRzeaGrkmuqvdK3cTHMpZPWm2dpj0m7oCOtKPp9JLLcIngm9+hciq9+W Vvk3uAToRYZP1YCN82G/HkNla2O3PvMC9xYuhZOx28vW7HVL7sRwaL+Hs4/YSnkz 0jKRM16zDtNlrdit1E7WMgsI7h1uao37aP/aU= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 652B08CBA0 for ; Tue, 29 Dec 2009 13:30: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 105528CB9F for ; Tue, 29 Dec 2009 13:30:51 -0500 (EST) Message-ID: <4B3A4B5C.7000501@pobox.com> Date: Tue, 29 Dec 2009 10:33:00 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: IETF TLS Working Group References: <4B33F445.4010203@bolyard.me> <4B33F7B4.3000101@pobox.com> <4B340609.9090008@bolyard.me> <051b01ca88a1$e6bc6920$0601a8c0@allison> In-Reply-To: <051b01ca88a1$e6bc6920$0601a8c0@allison> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4B5D75A0-F4A8-11DE-97D9-9D59EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2009 18:31:13 -0000 tom.petch wrote: > > Plenty of synonyms in Roget (vide 'junction') but I would go for > (TLS|security) context. Please don't use "context" to try to describe anything. It is an extremely overused term, and has a very vague meaning. Plus there are software libraries that call their data structures contexts, which would cause confusion if that context was not identical to whatever you start calling a context in the TLS spec. Mike From nelson@bolyard.me Tue Dec 29 14: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 AACE93A69ED for ; Tue, 29 Dec 2009 14:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_35=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 VWRU9axDvX-U for ; Tue, 29 Dec 2009 14:29:19 -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 CD5EC3A69B7 for ; Tue, 29 Dec 2009 14:29:18 -0800 (PST) Received: (qmail 20228 invoked from network); 29 Dec 2009 22:28:56 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 29 Dec 2009 22:28:56 -0000 Message-ID: <4B3A82A1.6060503@bolyard.me> Date: Tue, 29 Dec 2009 14:28:49 -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: <4B33F445.4010203@bolyard.me> <4B33F7B4.3000101@pobox.com> <4B340609.9090008@bolyard.me> <051b01ca88a1$e6bc6920$0601a8c0@allison> In-Reply-To: <051b01ca88a1$e6bc6920$0601a8c0@allison> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2009 22:29:19 -0000 On 2009-12-29 08:13 PST, tom.petch wrote: >>> Nelson B Bolyard wrote: >> The "thing" on which I wanted to hang the name "TLS channel" is (in some >> sense) defined by a cipher and a MAC and a pair of cipher keys and MAC >> keys. It is uniquely identified (IINM) by the contents of a pair of TLS >> Finished messages, which is probably why the TLS channel binding proposal >> wants to use the contents of the pair of TLS Finished messages as its >> identifier (IINM). > > I think that nailing a term to this concept is an excellent idea. > > As Marsh just said, and Nico amplified on 7Dec09, channel bindings refers > to the first such thing as long as subsequent renegotiations are bound > to the first (which the fixes under discussion would do); if they are not > bound, then each handshake would generate a new secure channel with its > own bindings which makes the use of 'channel' for 'thing' a bit flaky. Well, yes, it was my understanding that each handshake does indeed generate a new secure channel with its own bindings. Each has its own pair of Finished messages, which are the identifiers of the bound channel (are they not?) in the TLS channel binding proposal/draft/RFC (whatever it is today). Therefore, it would seem wrong to me to allow a "TLS channel", identified by the contents of one pair of finished messages, to be used to identify/bind to another channel that was the result of another handshake. In any case, I want to hang a name on that thing that changes with every handshake. Clearly the new renegotiation scheme creates another thing that can survive renegotiations, and that should also have a name that is distinct from the name for the thing I'm trying to name. > Back on 2Nov09, Nico seemed to refer to this thing as a TLS connection > (and cited Larry as using the term security context for the same > concept). If "TLS Channel" more accurately describes that thing that survives renegotiations, then I would withdraw my proposal to use that name for the thing that changes with every renegotiation. I am inclined to ask Nico to make that call. > But then, on 2Dec09, Eric agreed that TLS connection and TCP connection > were one-to-one which, since renegotiation can occur within a TCP > connection, would rule out TLS connection for this thing. Maybe we'd find some more ideas for names in some old standards such as ANSI X9.17 > Plenty of synonyms in Roget (vide 'junction') but I would go for > (TLS|security) context. > > Tom Petch Regards, /Nelson Bolyard From marsh@extendedsubset.com Tue Dec 29 14:56: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 27FFB3A68DD for ; Tue, 29 Dec 2009 14:56:35 -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.223, BAYES_20=-0.74, J_CHICKENPOX_35=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 hOPg2lgX36tT for ; Tue, 29 Dec 2009 14:56: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 3643E3A62C1 for ; Tue, 29 Dec 2009 14:56: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 1NPkz8-0009UY-7h; Tue, 29 Dec 2009 22:56:14 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 091486678; Tue, 29 Dec 2009 22:56: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: U2FsdGVkX19KJAspAlJPtH//rP+uPI4wSQhFTS5nIcU= Message-ID: <4B3A890A.1040506@extendedsubset.com> Date: Tue, 29 Dec 2009 16:56:10 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nelson B Bolyard References: <4B33F445.4010203@bolyard.me> <4B33F7B4.3000101@pobox.com> <4B340609.9090008@bolyard.me> <051b01ca88a1$e6bc6920$0601a8c0@allison> <4B3A82A1.6060503@bolyard.me> In-Reply-To: <4B3A82A1.6060503@bolyard.me> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF TLS Working Group Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2009 22:56:35 -0000 Nelson B Bolyard wrote: > On 2009-12-29 08:13 PST, tom.petch wrote: >>>> Nelson B Bolyard wrote: > >>> The "thing" on which I wanted to hang the name "TLS channel" is (in some >>> sense) defined by a cipher and a MAC and a pair of cipher keys and MAC >>> keys. It is uniquely identified (IINM) by the contents of a pair of TLS >>> Finished messages, which is probably why the TLS channel binding proposal >>> wants to use the contents of the pair of TLS Finished messages as its >>> identifier (IINM). >> I think that nailing a term to this concept is an excellent idea. >> >> As Marsh just said, and Nico amplified on 7Dec09, channel bindings refers >> to the first such thing as long as subsequent renegotiations are bound >> to the first (which the fixes under discussion would do); if they are not >> bound, then each handshake would generate a new secure channel with its >> own bindings which makes the use of 'channel' for 'thing' a bit flaky. > > Well, yes, it was my understanding that each handshake does indeed generate > a new secure channel with its own bindings. Each has its own pair of > Finished messages, which are the identifiers of the bound channel (are they > not?) in the TLS channel binding proposal/draft/RFC (whatever it is today). > Therefore, it would seem wrong to me to allow a "TLS channel", identified > by the contents of one pair of finished messages, to be used to > identify/bind to another channel that was the result of another handshake. > > In any case, I want to hang a name on that thing that changes with every > handshake. "Connection state" doesn't sound all that bad now. Probably I've been looking at it too much! > Clearly the new renegotiation scheme creates another thing that > can survive renegotiations, I don't think it creates a new thing, it just fulfills a guarantee that everyone thought had been there all along. > and that should also have a name that is > distinct from the name for the thing I'm trying to name. Everybody in the world (except us with our heads in the protocol specs and the implementation code) thinks of this as an "SSL socket" or "TLS connection". TLS is a "connection oriented" protocol, and the specs repeatedly use the term "connection" in talking about them. >> Back on 2Nov09, Nico seemed to refer to this thing as a TLS connection >> (and cited Larry as using the term security context for the same >> concept). > > If "TLS Channel" more accurately describes that thing that survives > renegotiations, It doesn't sound like it to me. "Channel" sounds deeply ambiguous and I'm still not sure that it's even the right concept. > then I would withdraw my proposal to use that name for the > thing that changes with every renegotiation. I am inclined to ask Nico to > make that call. > >> But then, on 2Dec09, Eric agreed that TLS connection and TCP connection >> were one-to-one which, since renegotiation can occur within a TCP >> connection, would rule out TLS connection for this thing. > > Maybe we'd find some more ideas for names in some old standards such as > ANSI X9.17 The goal was not to create a new thing, but to fix an existing thing. Perhaps we don't need to find new names, but standardize the existing usage. Hmmm, except that strangely there really wasn't much need to refer to an "instance of a session on a connection", so it never really developed a good term. >> Plenty of synonyms in Roget (vide 'junction') but I would go for >> (TLS|security) context. "Context" is what the MS SSPI calls it, but that is an extremely general interface which supports all kinds of auth packages. I think "context" ends up being an overly general name, to the point of meaninglessness. Regardless, I feel we should be prepared to ship the fix even if we don't have the nomenclature perfected. I believe in the importance of good names more than most, but in this case it's not worth holding up the protocol fix for even one more day for things that can be addressed in future documents. - Marsh From DPKemp@missi.ncsc.mil Wed Dec 30 09:53: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 C9D2C3A6958 for ; Wed, 30 Dec 2009 09:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_05=-1.11, 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 znECxzUHQCDn for ; Wed, 30 Dec 2009 09:53:51 -0800 (PST) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id C52B83A682A for ; Wed, 30 Dec 2009 09:53:51 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA8978.DEBE9B4C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 30 Dec 2009 12:52:35 -0500 Message-ID: <200912301753.nBUHrRw2021772@stingray.missi.ncsc.mil> In-Reply-To: <1b587cab0912280536u2fbfaa6eo1f1c28b3c3c6da05@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft thread-index: AcqHwvNWFWFsD5d6SOGoUYAcAHaNRwBs2tFw References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local><4B2FA22D.2090800@extendedsubset.com> <1b587cab0912280536u2fbfaa6eo1f1c28b3c3c6da05@mail.gmail.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 30 Dec 2009 17:53:53.0750 (UTC) FILETIME=[0D1C7F60:01CA8979] Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 30 Dec 2009 17:53:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA8978.DEBE9B4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Amazon and Google are free to accept SSLv2 as well as TLSv1.x-unpatched (minor MSbit unset) if they perceive the benefit of communicating to be greater than the risk of being attacked. That has no bearing on whether the protocol spec for TLSv1.x-patched requires aborting connections with bozo endpoints, which of course it should. Service providers/consumers can make their own choice of which protocol versions and ciphersuites to accept, with the knowledge that more restrictive choices will lock out some endpoints. It has always been thus. =20 Dave =20 =20 From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Monday, December 28, 2009 8:37 AM To: Yoav Nir Cc: tls@ietf.org Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft =20 =20 On Tue, Dec 22, 2009 at 8:21 AM, Yoav Nir wrote: On Dec 21, 2009, at 6:28 PM, Marsh Ray wrote: > Blumenthal, Uri - 0662 - MITLL wrote: > >> If the >> protocol spec demands aborting connection, it better have a damn good >> reason to do so - and more substantive than "some Steve decided it >> doesn't really matter to him if the peers connect or not". > > How about "remote endpoint doesn't pass the bozo test"? We do not discriminate against bozos. Seriously, servers are there to communicate. Amazon or Google are not going to turn away customers because their browsers are a little off. That's why they agree to work in SSLv2. =20 Oh yes we are :-)=20 =20 $ openssl s_client -ssl2 -connect www.google.com:443 CONNECTED(00000003) write:errno=3D54 =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 ------_=_NextPart_001_01CA8978.DEBE9B4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Amazon and Google are free to accept SSLv2 as well as = TLSv1.x-unpatched (minor MSbit unset) if they perceive the benefit of communicating to be = greater than the risk of being attacked.   That has no bearing on = whether the protocol spec for TLSv1.x-patched requires aborting connections with bozo endpoints, = which of course it should.   Service providers/consumers can make their = own choice of which protocol versions and ciphersuites to accept, with the knowledge = that more restrictive choices will lock out some endpoints.   It = has always been thus.

 

Dave

 

 

From:= tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = Ben Laurie
Sent: Monday, December 28, 2009 8:37 AM
To: Yoav Nir
Cc: tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated = draft

 

 

On Tue, Dec 22, 2009 at 8:21 AM, Yoav Nir <ynir@checkpoint.com> = wrote:


On Dec 21, 2009, at 6:28 PM, Marsh Ray wrote:

> Blumenthal, Uri - 0662 - MITLL wrote:
>

>> If the
>> protocol spec demands aborting connection, it better have a = damn good
>> reason to do so - and more substantive than "some Steve = decided it
>> doesn't really matter to him if the peers connect or = not".
>
> How about "remote endpoint doesn't pass the bozo = test"?

We do not discriminate against bozos.

Seriously, servers are there to communicate. Amazon or Google are not = going to turn away customers because their browsers are a little off. That's why = they agree to work in SSLv2.

 

Oh yes we are :-) 

 

$ openssl s_client -ssl2 -connect www.google.com:443

CONNECTED(00000003)

write:errno=3D54

 

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

 

------_=_NextPart_001_01CA8978.DEBE9B4C-- From uri@ll.mit.edu Wed Dec 30 10:14: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 041EC3A693E for ; Wed, 30 Dec 2009 10:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 tG0xDTtIJ7Cv for ; Wed, 30 Dec 2009 10:14:27 -0800 (PST) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id DA7EA3A68A7 for ; Wed, 30 Dec 2009 10:14:26 -0800 (PST) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBUIE2TO018842; Wed, 30 Dec 2009 13:14:02 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAjhaGBr; Wed Dec 30 12:58:57 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 30 Dec 2009 12:58:57 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'DPKemp@missi.ncsc.mil'" , "'tls@ietf.org'" Date: Wed, 30 Dec 2009 12:58:56 -0500 Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft Thread-Index: AcqHwvNWFWFsD5d6SOGoUYAcAHaNRwBs2tFwAADYvz8= Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854037@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: multipart/alternative; boundary="_000_90E934FC4BBC1946B3C27E673B4DB0E4A7EE854037LLE2K7BE01mit_" MIME-Version: 1.0 Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated 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, 30 Dec 2009 18:14:28 -0000 --_000_90E934FC4BBC1946B3C27E673B4DB0E4A7EE854037LLE2K7BE01mit_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmaW5kIGl0IGxlc3MgdGhhbiBzbWFydCAoYW5kIHZlcnkgY291bnRlci1wcm9kdWN0aXZlKSB0 cnlpbmcgdG8gaGFyZC1jb2RlIHRvbyBtdWNoIHBvbGljeSBpbnRvIHRoZSBwcm90b2NvbCBzcGVj Lg0KDQpZZXMgc29tZSBwb2xpY3kgdW5mb3J0dW5hdGVseSBoYXMgdG8gYmUgdGhlcmUuDQoNClJl Z2FyZHMsDQpVcmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHRs cy1ib3VuY2VzQGlldGYub3JnIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4NClRvOiB0bHNAaWV0Zi5v cmcgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IFdlZCBEZWMgMzAgMTI6NTI6MzUgMjAwOQ0KU3ViamVj dDogUmU6IFtUTFNdIFNDU1YgdnMgUkkgd2hlbiBib3RoIHNwZWNpZmllZC4gV2FzOiBVcGRhdGVk IGRyYWZ0DQoNCkFtYXpvbiBhbmQgR29vZ2xlIGFyZSBmcmVlIHRvIGFjY2VwdCBTU0x2MiBhcyB3 ZWxsIGFzIFRMU3YxLngtdW5wYXRjaGVkIChtaW5vciBNU2JpdCB1bnNldCkgaWYgdGhleSBwZXJj ZWl2ZSB0aGUgYmVuZWZpdCBvZiBjb21tdW5pY2F0aW5nIHRvIGJlIGdyZWF0ZXIgdGhhbiB0aGUg cmlzayBvZiBiZWluZyBhdHRhY2tlZC4gICBUaGF0IGhhcyBubyBiZWFyaW5nIG9uIHdoZXRoZXIg dGhlIHByb3RvY29sIHNwZWMgZm9yIFRMU3YxLngtcGF0Y2hlZCByZXF1aXJlcyBhYm9ydGluZyBj b25uZWN0aW9ucyB3aXRoIGJvem8gZW5kcG9pbnRzLCB3aGljaCBvZiBjb3Vyc2UgaXQgc2hvdWxk LiAgIFNlcnZpY2UgcHJvdmlkZXJzL2NvbnN1bWVycyBjYW4gbWFrZSB0aGVpciBvd24gY2hvaWNl IG9mIHdoaWNoIHByb3RvY29sIHZlcnNpb25zIGFuZCBjaXBoZXJzdWl0ZXMgdG8gYWNjZXB0LCB3 aXRoIHRoZSBrbm93bGVkZ2UgdGhhdCBtb3JlIHJlc3RyaWN0aXZlIGNob2ljZXMgd2lsbCBsb2Nr IG91dCBzb21lIGVuZHBvaW50cy4gICBJdCBoYXMgYWx3YXlzIGJlZW4gdGh1cy4NCg0KRGF2ZQ0K DQoNCkZyb206IHRscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCZW4gTGF1cmllDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDI4LCAy MDA5IDg6MzcgQU0NClRvOiBZb2F2IE5pcg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtUTFNdIFNDU1YgdnMgUkkgd2hlbiBib3RoIHNwZWNpZmllZC4gV2FzOiBVcGRhdGVkIGRyYWZ0 DQoNCg0KT24gVHVlLCBEZWMgMjIsIDIwMDkgYXQgODoyMSBBTSwgWW9hdiBOaXIgPHluaXJAY2hl Y2twb2ludC5jb208bWFpbHRvOnluaXJAY2hlY2twb2ludC5jb20+PiB3cm90ZToNCg0KT24gRGVj IDIxLCAyMDA5LCBhdCA2OjI4IFBNLCBNYXJzaCBSYXkgd3JvdGU6DQoNCj4gQmx1bWVudGhhbCwg VXJpIC0gMDY2MiAtIE1JVExMIHdyb3RlOg0KPg0KPj4gSWYgdGhlDQo+PiBwcm90b2NvbCBzcGVj IGRlbWFuZHMgYWJvcnRpbmcgY29ubmVjdGlvbiwgaXQgYmV0dGVyIGhhdmUgYSBkYW1uIGdvb2QN Cj4+IHJlYXNvbiB0byBkbyBzbyAtIGFuZCBtb3JlIHN1YnN0YW50aXZlIHRoYW4gInNvbWUgU3Rl dmUgZGVjaWRlZCBpdA0KPj4gZG9lc24ndCByZWFsbHkgbWF0dGVyIHRvIGhpbSBpZiB0aGUgcGVl cnMgY29ubmVjdCBvciBub3QiLg0KPg0KPiBIb3cgYWJvdXQgInJlbW90ZSBlbmRwb2ludCBkb2Vz bid0IHBhc3MgdGhlIGJvem8gdGVzdCI/DQpXZSBkbyBub3QgZGlzY3JpbWluYXRlIGFnYWluc3Qg Ym96b3MuDQoNClNlcmlvdXNseSwgc2VydmVycyBhcmUgdGhlcmUgdG8gY29tbXVuaWNhdGUuIEFt YXpvbiBvciBHb29nbGUgYXJlIG5vdCBnb2luZyB0byB0dXJuIGF3YXkgY3VzdG9tZXJzIGJlY2F1 c2UgdGhlaXIgYnJvd3NlcnMgYXJlIGEgbGl0dGxlIG9mZi4gVGhhdCdzIHdoeSB0aGV5IGFncmVl IHRvIHdvcmsgaW4gU1NMdjIuDQoNCk9oIHllcyB3ZSBhcmUgOi0pDQoNCiQgb3BlbnNzbCBzX2Ns aWVudCAtc3NsMiAtY29ubmVjdCB3d3cuZ29vZ2xlLmNvbTo0NDM8aHR0cDovL3d3dy5nb29nbGUu Y29tOjQ0Mz4NCkNPTk5FQ1RFRCgwMDAwMDAwMykNCndyaXRlOmVycm5vPTU0DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0 DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_90E934FC4BBC1946B3C27E673B4DB0E4A7EE854037LLE2K7BE01mit_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBl IiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KDQoNCjxtZXRhIG5hbWU9 R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4N CjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQog PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5n PUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2 eSBmYWNlPUFyaWFsPg0KSSBmaW5kIGl0IGxlc3MgdGhhbiBzbWFydCAoYW5kIHZlcnkgY291bnRl ci1wcm9kdWN0aXZlKSB0cnlpbmcgdG8gaGFyZC1jb2RlIHRvbyBtdWNoIHBvbGljeSBpbnRvIHRo ZSBwcm90b2NvbCBzcGVjLjxicj48YnI+WWVzIHNvbWUgcG9saWN5IHVuZm9ydHVuYXRlbHkgaGFz IHRvIGJlIHRoZXJlLiA8YnI+DTxicj5SZWdhcmRzLA08YnI+VXJpPC9mb250PjwvZGl2Pg0KPGJy PjxkaXY+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0K PGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IHRscy1ib3VuY2VzQGlldGYu b3JnICZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDsNPGJyPjxiPlRvPC9iPjogdGxzQGlldGYu b3JnICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TZW50PC9iPjogV2VkIERlYyAzMCAxMjo1 MjozNSAyMDA5PGJyPjxiPlN1YmplY3Q8L2I+OiBSZTogW1RMU10gU0NTViB2cyBSSSB3aGVuIGJv dGggc3BlY2lmaWVkLiBXYXM6IFVwZGF0ZWQgZHJhZnQNPGJyPjwvZm9udD48YnI+PC9kaXY+DQoN Cg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5BbWF6b24gYW5kIEdvb2dsZSBhcmUgZnJlZSB0byBhY2NlcHQgU1NMdjIg YXMgd2VsbCBhcyBUTFN2MS54LXVucGF0Y2hlZA0KKG1pbm9yIE1TYml0IHVuc2V0KSBpZiB0aGV5 IHBlcmNlaXZlIHRoZSBiZW5lZml0IG9mIGNvbW11bmljYXRpbmcgdG8gYmUgZ3JlYXRlcg0KdGhh biB0aGUgcmlzayBvZiBiZWluZyBhdHRhY2tlZC4mbmJzcDsmbmJzcDsgVGhhdCBoYXMgbm8gYmVh cmluZyBvbiB3aGV0aGVyIHRoZSBwcm90b2NvbCBzcGVjDQpmb3IgVExTdjEueC1wYXRjaGVkIHJl cXVpcmVzIGFib3J0aW5nIGNvbm5lY3Rpb25zIHdpdGggYm96byBlbmRwb2ludHMsIHdoaWNoIG9m DQpjb3Vyc2UgaXQgc2hvdWxkLiZuYnNwOyAmbmJzcDtTZXJ2aWNlIHByb3ZpZGVycy9jb25zdW1l cnMgY2FuIG1ha2UgdGhlaXIgb3duIGNob2ljZSBvZg0Kd2hpY2ggcHJvdG9jb2wgdmVyc2lvbnMg YW5kIGNpcGhlcnN1aXRlcyB0byBhY2NlcHQsIHdpdGggdGhlIGtub3dsZWRnZSB0aGF0DQptb3Jl IHJlc3RyaWN0aXZlIGNob2ljZXMgd2lsbCBsb2NrIG91dCBzb21lIGVuZHBvaW50cy4mbmJzcDsm bmJzcDsgSXQgaGFzIGFsd2F5cyBiZWVuDQp0aHVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFG NDk3RCc+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4NCnRscy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+QmVuDQpMYXVyaWU8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciAyOCwgMjAw OSA4OjM3IEFNPGJyPg0KPGI+VG86PC9iPiBZb2F2IE5pcjxicj4NCjxiPkNjOjwvYj4gdGxzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBTQ1NWIHZzIFJJIHdoZW4gYm90 aCBzcGVjaWZpZWQuIFdhczogVXBkYXRlZCBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJzcDs8 L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5PbiBUdWUsIERlYyAyMiwg MjAwOSBhdCA4OjIxIEFNLCBZb2F2IE5pciAmbHQ7PGENCmhyZWY9Im1haWx0bzp5bmlyQGNoZWNr cG9pbnQuY29tIj55bmlyQGNoZWNrcG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQpPbiBEZWMgMjEsIDIwMDks IGF0IDY6MjggUE0sIE1hcnNoIFJheSB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEJsdW1lbnRoYWws IFVyaSAtIDA2NjIgLSBNSVRMTCB3cm90ZTo8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz4mZ3Q7Jmd0OyBJZiB0aGU8YnI+DQomZ3Q7Jmd0OyBwcm90b2NvbCBzcGVjIGRlbWFu ZHMgYWJvcnRpbmcgY29ubmVjdGlvbiwgaXQgYmV0dGVyIGhhdmUgYSBkYW1uIGdvb2Q8YnI+DQom Z3Q7Jmd0OyByZWFzb24gdG8gZG8gc28gLSBhbmQgbW9yZSBzdWJzdGFudGl2ZSB0aGFuICZxdW90 O3NvbWUgU3RldmUgZGVjaWRlZA0KaXQ8YnI+DQomZ3Q7Jmd0OyBkb2Vzbid0IHJlYWxseSBtYXR0 ZXIgdG8gaGltIGlmIHRoZSBwZWVycyBjb25uZWN0IG9yIG5vdCZxdW90Oy48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBIb3cgYWJvdXQgJnF1b3Q7cmVtb3RlIGVuZHBvaW50IGRvZXNuJ3QgcGFzcyB0aGUg Ym96byB0ZXN0JnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPldlIGRvIG5vdCBkaXNjcmltaW5hdGUgYWdhaW5zdCBib3pvcy48YnI+DQo8YnI+DQpT ZXJpb3VzbHksIHNlcnZlcnMgYXJlIHRoZXJlIHRvIGNvbW11bmljYXRlLiBBbWF6b24gb3IgR29v Z2xlIGFyZSBub3QgZ29pbmcgdG8NCnR1cm4gYXdheSBjdXN0b21lcnMgYmVjYXVzZSB0aGVpciBi cm93c2VycyBhcmUgYSBsaXR0bGUgb2ZmLiBUaGF0J3Mgd2h5IHRoZXkNCmFncmVlIHRvIHdvcmsg aW4gU1NMdjIuPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD5PaCB5ZXMgd2UgYXJlIDotKSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiQgb3BlbnNzbCBzX2NsaWVudCAtc3Ns MiAtY29ubmVjdCA8YQ0KaHJlZj0iaHR0cDovL3d3dy5nb29nbGUuY29tOjQ0MyI+d3d3Lmdvb2ds ZS5jb206NDQzPC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPkNPTk5FQ1RFRCgwMDAwMDAwMyk8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD53cml0ZTplcnJubz01NDxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDsN Cm1hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4nPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRM U0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+ DQo= --_000_90E934FC4BBC1946B3C27E673B4DB0E4A7EE854037LLE2K7BE01mit_-- From ravi@findravi.com Wed Dec 30 16: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 E89B43A6986 for ; Wed, 30 Dec 2009 16:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=-1.442, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 f9WiijsEBB55 for ; Wed, 30 Dec 2009 16:47:11 -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 DBDE53A6966 for ; Wed, 30 Dec 2009 16:47:11 -0800 (PST) Received: by pzk6 with SMTP id 6so9708532pzk.29 for ; Wed, 30 Dec 2009 16:46:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.248.7 with SMTP id v7mr12852350wah.92.1262220409250; Wed, 30 Dec 2009 16:46:49 -0800 (PST) Date: Wed, 30 Dec 2009 16:46:49 -0800 Message-ID: <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e64c3d981f2493047bfb97dc Subject: Re: [TLS] sessions, contexts, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2009 00:47:13 -0000 --0016e64c3d981f2493047bfb97dc Content-Type: text/plain; charset=UTF-8 Does something along these lines work as a pedagogical device? Nodes characterized by the parameters of relevance. A root node, three types of ways to spawn a child node. What a child inherits from parent, etc... At the end of a TLS handshake, the Client and the Server share six key pieces of information: (i) a session-id /*Public information */ (ii) a shared master-secret /*Secret. Known only to Client and Server */ (iii) the client-random and /* May be public or secret */ (iv) the server-random. /*May be public or secret*/ (v) authentication knowledge /* Namely, the Client MAY know that is has authenticated the Server (in practice this almost always is true). The Server MAY know that it has authenticated the Client (relatively rare in practice, but an important sub-category). (vi) renegotiation-information /*The newly introduced RI field at the end of the handshake. */ When the Client and a Server share NONE of the above six pieces of data, the Client will typically initiate a completely fresh session using the FULL handshake. Such a session is called a ROOT session. A Client and a Server who have completed a ROOT session can engage in further handshakes to create new sessions, which in turn can create further sessions. Treating each session as a node in a graph we can get a tree rooted at the ROOT. Each node can spawn a child node using three different techniques as follows: i) A node can create a child-node by performing an abbreviated handshake. Such an abbreviated-child inherits the session-id, the shared master-secret and the authentication-knowledge, from its parent (these CANNOT change). It gets new client-random, server-random and starts afresh with renegotiation-information. This technique of spawning a child node is usually used for efficiency considerations (abbrv. handshake requires no PKI operations, which is why it cannot be used to update authentication-knowledge of the other end either). The creation of such a child-node does NOT result in the previous node becoming inactive. ii) A node can create a child node by performing renegotiation, followed by a full handshake. Such a full-renego-child, starts afresh with new values for all of the first five parameters. The only parameter which keeps it tied to this tree is the renegotiation-information, which is derived from the handshake and the parent-node's renegotiation-information. The primary use-case for this technique is to update authentication-knowledge of the Server (i.e. does it know who the Client is?). The creation of such a child node means the parent node can no longer be used. iii) A node can create a child node by performing renegotiation followed by an abbreviated handshake. Such a abbrv-renego-child inherits the session-id, shared-master-secret and authentication-information of its parent. There is a new client-random and server-random, and as in a full-renego-child, the renegotiation-information is derived from the handshake and the the renegotiation-information of its parent. I do not know why this use-case exists; the encryption/hashing keys change but it is questionable if that adds any protection. The creation of such a child node means the parent node can no longer be used. Observe that each of the different child nodes can give birth to any of the other three types of children. --0016e64c3d981f2493047bfb97dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Does something along these lines work as a pedagogical device? Nodes charac= terized by the parameters of relevance. A root node, three types of ways to= spawn a child node. What a child inherits from parent, etc...

At th= e end of a TLS handshake, the Client and the Server share six key pieces of= information:
(i) a session-id=C2=A0 /*Public information */
(ii) a shared master-secr= et /*Secret. Known only to Client and Server */
(iii) the client-random = and /* May be public or secret */
(iv) the server-random.=C2=A0 /*May be= public or secret*/
(v) authentication knowledge /* Namely, the Client MAY know that is has aut= henticated the Server (in practice this almost always is true). The Server = MAY know that it has authenticated the Client (relatively rare in practice,= but an important sub-category).
(vi) renegotiation-information /*The newly introduced RI field at the end o= f the handshake. */


When the=C2=A0 Client and a Server share NONE of the above six pieces o= f data, the Client will typically initiate a completely fresh session using= the FULL handshake.=C2=A0 Such a session is called a ROOT session. A Clien= t and a Server who have completed a ROOT session can engage in further hand= shakes to create new sessions, which in turn can create further sessions. T= reating each session as a node in a graph we can get a tree rooted at the R= OOT.

Each node can spawn a child node using three different techniques as fo= llows:

i) A node can create a child-node by performing an abbreviate= d handshake. Such an abbreviated-child inherits the session-id, the shared = master-secret and the authentication-knowledge, from its parent (these CANN= OT change). It gets new client-random, server-random and starts afresh with= renegotiation-information.=C2=A0 This technique of spawning a child node i= s usually used for efficiency considerations (abbrv. handshake requires no = PKI operations, which is why it cannot be used to update authentication-kno= wledge of the other end either).=C2=A0 The creation of such a child-node do= es NOT result in the previous node becoming inactive.

ii) A node can create a child node by performing renegotiation, followe= d by a full handshake. Such a full-renego-child, starts afresh with new val= ues for all of the first five parameters. The only parameter which keeps it= tied to this tree is the renegotiation-information, which is derived from = the handshake and the parent-node's renegotiation-information. The prim= ary use-case for this technique is=C2=A0 to update authentication-knowledge= of the Server (i.e. does it know who the Client is?).=C2=A0 The creation o= f such a child node means the parent node can no longer be used.

iii) A node can create a child node by performing renegotiation followe= d by an abbreviated handshake. Such a abbrv-renego-child inherits the sessi= on-id, shared-master-secret and authentication-information of its parent. T= here is a new client-random and server-random, and as in a full-renego-chil= d, the renegotiation-information is derived from the handshake and the the = renegotiation-information of its parent.=C2=A0 I do not know why this use-c= ase exists; the encryption/hashing keys change but it is questionable if th= at adds any protection. The creation of such a child node means the parent = node can no longer be used.

Observe that each of the different child nodes can give birth to any of= the other three types of children.

--0016e64c3d981f2493047bfb97dc-- From djhopwood@googlemail.com Wed Dec 30 18:17: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 ECA4B3A6956 for ; Wed, 30 Dec 2009 18:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-0.730, 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 saxscm0qzfaF for ; Wed, 30 Dec 2009 18:17: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 A41BD3A69E6 for ; Wed, 30 Dec 2009 18:17:15 -0800 (PST) Received: by ewy6 with SMTP id 6so11084386ewy.29 for ; Wed, 30 Dec 2009 18:16: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=8HhBvpWqyhTRen2z07ctEXPjpGxka/Dm/ed5PyVKXRs=; b=d30n8E9jQju4oDBn4/WemPT5W/FHO0OfFrQeUGpcKy1Gd8Xg41S0XH4RNTIDQo1GrY hgTLgYYhWLtgWfIQ+G/BPQP3SjahHbpstPpleVIdU6zptoWoYwqygP00ypN+PVw6r9pR n6JMFqqTqzGcm6XK10RFElCBcDyoRS3BS32GI= 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=TsIq31i0C0T73HA6JSIYXqjHO50prElY+JtpFxjD3urA/qRi6fjAujwpgrxkNJS8tq yApm2UMtz5+0Pt8enXITUVKEtZO8+UBBuaRJmwpve1DyYBKcdDCd6O0A1N5iyVUKi0OH Qioi5F0PH1xvMlmdEC3NnDAMxMSchRM+IePXo= Received: by 10.213.42.210 with SMTP id t18mr7331538ebe.49.1262225812223; Wed, 30 Dec 2009 18:16:52 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 14sm9932128ewy.7.2009.12.30.18.16.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Dec 2009 18:16:51 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B3C0976.7020405@jacaranda.org> Date: Thu, 31 Dec 2009 02:16: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: <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com> In-Reply-To: <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4E7490C5F99214D91B54A003" Subject: Re: [TLS] sessions, contexts, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2009 02:17:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E7490C5F99214D91B54A003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ravi Ganesan wrote: > Each node can spawn a child node using three different techniques as > follows: >=20 > i) A node can create a child-node by performing an abbreviated handshak= e. > Such an abbreviated-child inherits the session-id, the shared master-se= cret > and the authentication-knowledge, from its parent (these CANNOT change)= =2E It > gets new client-random, server-random and starts afresh with > renegotiation-information. This technique of spawning a child node is > usually used for efficiency considerations (abbrv. handshake requires n= o PKI > operations, which is why it cannot be used to update > authentication-knowledge of the other end either). The creation of suc= h a > child-node does NOT result in the previous node becoming inactive. >=20 > ii) A node can create a child node by performing renegotiation, followe= d by > a full handshake. Such a full-renego-child, starts afresh with new valu= es > for all of the first five parameters. The only parameter which keeps it= tied > to this tree is the renegotiation-information, which is derived from th= e > handshake and the parent-node's renegotiation-information. The primary > use-case for this technique is to update authentication-knowledge of t= he > Server (i.e. does it know who the Client is?). The creation of such a = child > node means the parent node can no longer be used. That (the last sentence) is not the case, as far as I'm aware. Renegotiat= ing on some connection currently associated with a session does not mean that= that session can no longer be resumed. > iii) A node can create a child node by performing renegotiation followe= d by > an abbreviated handshake. Such a abbrv-renego-child inherits the sessio= n-id, > shared-master-secret and authentication-information of its parent. Ther= e is > a new client-random and server-random, and as in a full-renego-child, t= he > renegotiation-information is derived from the handshake and the the > renegotiation-information of its parent. I do not know why this use-ca= se > exists; the encryption/hashing keys change but it is questionable if th= at > adds any protection. The creation of such a child node means the parent= node > can no longer be used. Ditto. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig4E7490C5F99214D91B54A003 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/ iF4EAREIAAYFAks8CX8ACgkQWUc8YzyzqAeX+gD/d3rq241CePbfwvURey9kfwRs UKt1EOp0AYRo/Fqv7ysA/Am4sEwYKDaPnnHW987xTTe5wRIvXem00XZMgftZgRko =7SSc -----END PGP SIGNATURE----- --------------enig4E7490C5F99214D91B54A003-- From ravi@findravi.com Wed Dec 30 22:23: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 9A5203A6A77 for ; Wed, 30 Dec 2009 22:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 mJbnJFaF9jOt for ; Wed, 30 Dec 2009 22:23:06 -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 DAEA73A6A19 for ; Wed, 30 Dec 2009 22:21:47 -0800 (PST) Received: by pwi20 with SMTP id 20so8402703pwi.29 for ; Wed, 30 Dec 2009 22:20:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.253.6 with SMTP id a6mr8879191wai.209.1262240415714; Wed, 30 Dec 2009 22:20:15 -0800 (PST) Date: Wed, 30 Dec 2009 22:20:15 -0800 Message-ID: <3561bdcc0912302220t7fad9ccfqf5103e6f120288ba@mail.gmail.com> From: Ravi Ganesan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e68786dd999277047c003fb2 Subject: [TLS] renego, patricide, putting out to stud, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2009 06:23:10 -0000 --0016e68786dd999277047c003fb2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> Ravi Ganesan wrote: >> ii) A node can create a child node by performing renegotiation, followed= by >> a full handshake. Such a full-renego-child, starts afresh with new value= s >> for all of the first five parameters. The only parameter which keeps it = tied >> to this tree is the renegotiation-information, which is derived from the >> handshake and the parent-node's renegotiation-information. The primary >> use-case for this technique is to update authentication-knowledge of th= e >> Server (i.e. does it know who the Client is?). The creation of such a c= hild >> node means the parent node can no longer be used. >That (the last sentence) is not the case, as far as I'm aware. Renegotiati= ng >on some connection currently associated with a session does not mean that >that session can no longer be resumed. >David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com What I meant by 'that node can no longer be used', is that since the effective encryption/hashing keys have been rolled over, trying to send data using the values in that node to the side should not work. In that sense either of the renego child nodes renders its parent inactive. It did occur to me that the node while it cannot be 'used' (per my def) might still be able to have progeny (put out to stud if you will!). I just figured that one could get an identical result by using the parameters in the child to do the "resume", and that would be preferable. --0016e68786dd999277047c003fb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
>> Ravi Ganesan wrote:
>> ii) A node can create a child=
 node by performing renegotiation, followed by
>> a full handshake=
. Such a full-renego-child, starts afresh with new values
>> for a=
ll of the first five parameters. The only parameter which keeps it tied

>> to this tree is the renegotiation-information, which is derived fr=
om the
>> handshake and the parent-node's renegotiation-inform=
ation. The primary
>> use-case for this technique is  to update au=
thentication-knowledge of the

>> Server (i.e. does it know who the Client is?).  The creation of su=
ch a child
>> node means the parent node can no longer be used.
>That (the last sentence) is not the case, as far as I'm aware.=
 Renegotiating

>on some connection currently associated with a session does not mean th=
at
>that session can no longer be resumed.
 
>David-Sarah Ho=
pwood  =E2=9A=A5  http://davidsarah.livejournal.com


What I meant by 'that node can no longer be used', is that sinc=
e the effective encryption/hashing keys have been rolled over, 
trying t=
o send data using the values in that node to the side should not work. In t=
hat sense either of the renego child nodes renders its parent inactive.

It did occur to me that the node while it cannot be 'used' (per my =
def) might still be able to have progeny (put out to stud if you will!). I just figured that one could get an identical result by using the parame=
ters in the child to do the "resume", and that would be preferabl=
e.


--0016e68786dd999277047c003fb2-- From cfinss@dial.pipex.com Thu Dec 31 01:35: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 D2E4E3A696C for ; Thu, 31 Dec 2009 01:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_50=0.001, J_CHICKENPOX_35=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 IjFnL4X61bXv for ; Thu, 31 Dec 2009 01:35:21 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id F0D0D3A6977 for ; Thu, 31 Dec 2009 01:35:20 -0800 (PST) X-Trace: 315683474/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.135/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.135 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFAIr/O0s+vGmH/2dsb2JhbACCWi2FK4hLwxoKgiKCBQQ X-IronPort-AV: E=Sophos;i="4.47,481,1257120000"; d="scan'208";a="315683474" X-IP-Direction: IN Received: from 1cust135.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.135]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 09:34:59 +0000 Message-ID: <001b01ca89f4$30f57a60$0601a8c0@allison> From: "tom.petch" To: "Marsh Ray" , "Nelson B Bolyard" References: <4B33F445.4010203@bolyard.me><4B33F7B4.3000101@pobox.com> <4B340609.9090008@bolyard.me> <051b01ca88a1$e6bc6920$0601a8c0@allison><4B3A82A1.6060503@bolyard.me> <4B3A890A.1040506@extendedsubset.com> Date: Thu, 31 Dec 2009 09:33:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: IETF TLS Working Group Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 09:35:22 -0000 ----- Original Message ----- From: "Marsh Ray" Subject: Re: [TLS] Naming that TLS session/connection instance thing > Nelson B Bolyard wrote: > > On 2009-12-29 08:13 PST, tom.petch wrote: > >>>> Nelson B Bolyard wrote: > > > >>> The "thing" on which I wanted to hang the name "TLS channel" is (in some > >>> sense) defined by a cipher and a MAC and a pair of cipher keys and MAC > >>> keys. It is uniquely identified (IINM) by the contents of a pair of TLS > >>> Finished messages, which is probably why the TLS channel binding proposal > >>> wants to use the contents of the pair of TLS Finished messages as its > >>> identifier (IINM). > >> I think that nailing a term to this concept is an excellent idea. > >> > >> As Marsh just said, and Nico amplified on 7Dec09, channel bindings refers > >> to the first such thing as long as subsequent renegotiations are bound > >> to the first (which the fixes under discussion would do); if they are not > >> bound, then each handshake would generate a new secure channel with its > >> own bindings which makes the use of 'channel' for 'thing' a bit flaky. > > > > Well, yes, it was my understanding that each handshake does indeed generate > > a new secure channel with its own bindings. Each has its own pair of > > Finished messages, which are the identifiers of the bound channel (are they > > not?) in the TLS channel binding proposal/draft/RFC (whatever it is today). > > Therefore, it would seem wrong to me to allow a "TLS channel", identified > > by the contents of one pair of finished messages, to be used to > > identify/bind to another channel that was the result of another handshake. > > > > In any case, I want to hang a name on that thing that changes with every > > handshake. > > "Connection state" doesn't sound all that bad now. Probably I've been > looking at it too much! > > > Clearly the new renegotiation scheme creates another thing that > > can survive renegotiations, > > I don't think it creates a new thing, it just fulfills a guarantee that > everyone thought had been there all along. > > > and that should also have a name that is > > distinct from the name for the thing I'm trying to name. > > Everybody in the world (except us with our heads in the protocol specs > and the implementation code) thinks of this as an "SSL socket" or "TLS > connection". > > TLS is a "connection oriented" protocol, and the specs repeatedly use > the term "connection" in talking about them. > > >> Back on 2Nov09, Nico seemed to refer to this thing as a TLS connection > >> (and cited Larry as using the term security context for the same > >> concept). > > > > If "TLS Channel" more accurately describes that thing that survives > > renegotiations, > > It doesn't sound like it to me. "Channel" sounds deeply ambiguous and > I'm still not sure that it's even the right concept. > > > then I would withdraw my proposal to use that name for the > > thing that changes with every renegotiation. I am inclined to ask Nico to > > make that call. > > > >> But then, on 2Dec09, Eric agreed that TLS connection and TCP connection > >> were one-to-one which, since renegotiation can occur within a TCP > >> connection, would rule out TLS connection for this thing. > > > > Maybe we'd find some more ideas for names in some old standards such as > > ANSI X9.17 > > The goal was not to create a new thing, but to fix an existing thing. > Perhaps we don't need to find new names, but standardize the existing > usage. Hmmm, except that strangely there really wasn't much need to > refer to an "instance of a session on a connection", so it never really > developed a good term. But.... The lengthy threads over the past eight weeks have tripped over the lack of terminology several times and there has also been some consensus that RFC5246 and its predecessors are not as easy to follow as they might be for their use of session, connection, renegotiation, rehandshake,... (And I still think that there is an ambiguity in the I-D that I struggle to communicate because of this lack). And Nico has said he wants this clarified as part of channel binding suggesting that "draft-altman-tls-channel-bindings, which defines (or soon will) the term ought to update RFC5246" (3Dec09) We already have thing1, thing2, thing3, ... we are not creating anything new, we just do not have terms for them, which costs time in misunderstandings and, perhaps, makes defects such as the current one harder to spot. For myself, I have litle concern as to what we call this if only we could agree on a name; connection state would be fine (as would section, link...) . And then we should go on to agree a name for the thing that - with the fix - survives renegotiations; etc. Nico may have Secure Channel lined up for that. Tom Petch > >> Plenty of synonyms in Roget (vide 'junction') but I would go for > >> (TLS|security) context. > > "Context" is what the MS SSPI calls it, but that is an extremely general > interface which supports all kinds of auth packages. I think "context" > ends up being an overly general name, to the point of meaninglessness. > > Regardless, I feel we should be prepared to ship the fix even if we > don't have the nomenclature perfected. I believe in the importance of > good names more than most, but in this case it's not worth holding up > the protocol fix for even one more day for things that can be addressed > in future documents. > > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From cfinss@dial.pipex.com Thu Dec 31 05:42: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 7114A3A67FD for ; Thu, 31 Dec 2009 05:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovUMWn3EtNzj for ; Thu, 31 Dec 2009 05:42:38 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 196A73A680B for ; Thu, 31 Dec 2009 05:42:37 -0800 (PST) X-Trace: 280924541/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.62/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.62 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EAPY4PEs+vGk+/2dsb2JhbACCWxh2hEqIS7VdjTsKgSOCLlYE X-IronPort-AV: E=Sophos;i="4.47,482,1257120000"; d="scan'208";a="280924541" X-IP-Direction: IN Received: from 1cust62.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.62]) by smtp.pipex.tiscali.co.uk with SMTP; 31 Dec 2009 13:42:16 +0000 Message-ID: <000601ca8a16$bd002f60$0601a8c0@allison> From: "tom.petch" To: "Ravi Ganesan" , References: <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com> Date: Thu, 31 Dec 2009 13:36:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [TLS] sessions, contexts, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 13:42:39 -0000 ---- Original Message ----- From: "Ravi Ganesan" Sent: Thursday, December 31, 2009 1:46 AM > Does something along these lines work as a pedagogical device? Nodes > characterized by the parameters of relevance. A root node, three types of > ways to spawn a child node. What a child inherits from parent, etc... > > At the end of a TLS handshake, the Client and the Server share six key > pieces of information: > (i) a session-id /*Public information */ > (ii) a shared master-secret /*Secret. Known only to Client and Server */ > (iii) the client-random and /* May be public or secret */ > (iv) the server-random. /*May be public or secret*/ > (v) authentication knowledge /* Namely, the Client MAY know that is has > authenticated the Server (in practice this almost always is true). The > Server MAY know that it has authenticated the Client (relatively rare in > practice, but an important sub-category). > (vi) renegotiation-information /*The newly introduced RI field at the end of > the handshake. */ > > When the Client and a Server share NONE of the above six pieces of data, > the Client will typically initiate a completely fresh session using the FULL > handshake. Such a session is called a ROOT session. A Client and a Server > who have completed a ROOT session can engage in further handshakes to create > new sessions, which in turn can create further sessions. Treating each > session as a node in a graph we can get a tree rooted at the ROOT. I fear that this muddies the waters. You seem to be using session for what Nelson would call - pro tem - 'that TLS session/connection instance thing'. I think this wrong as session already has a separate semantic. > Each node can spawn a child node using three different techniques as > follows: > > i) A node can create a child-node by performing an abbreviated handshake. > Such an abbreviated-child inherits the session-id, the shared master-secret > and the authentication-knowledge, from its parent (these CANNOT change). It > gets new client-random, server-random and starts afresh with > renegotiation-information. This technique of spawning a child node is > usually used for efficiency considerations (abbrv. handshake requires no PKI > operations, which is why it cannot be used to update > authentication-knowledge of the other end either). The creation of such a > child-node does NOT result in the previous node becoming inactive. > > ii) A node can create a child node by performing renegotiation, followed by > a full handshake. Such a full-renego-child, starts afresh with new values Again, I think this muddies the waters. Renegotiation is not defined, but the text in RFC5246 makes it clear to me that it starts with HelloRequest or ClientHello and what is this last if not a handshake? Abolish the word renegotiation from this lexicon:-) When we have the right terminology for 'that TLS session/connection instance thing', then we will be able to characterise types of handshakes better and should have no need for it. Tom Petch > for all of the first five parameters. The only parameter which keeps it tied > to this tree is the renegotiation-information, which is derived from the > handshake and the parent-node's renegotiation-information. The primary > use-case for this technique is to update authentication-knowledge of the > Server (i.e. does it know who the Client is?). The creation of such a child > node means the parent node can no longer be used. > > iii) A node can create a child node by performing renegotiation followed by > an abbreviated handshake. Such a abbrv-renego-child inherits the session-id, > shared-master-secret and authentication-information of its parent. There is > a new client-random and server-random, and as in a full-renego-child, the > renegotiation-information is derived from the handshake and the the > renegotiation-information of its parent. I do not know why this use-case > exists; the encryption/hashing keys change but it is questionable if that > adds any protection. The creation of such a child node means the parent node > can no longer be used. > > Observe that each of the different child nodes can give birth to any of the > other three types of children. > -------------------------------------------------------------------------------- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From marsh@extendedsubset.com Thu Dec 31 08:55: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 CC9563A6A38 for ; Thu, 31 Dec 2009 08:55:03 -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 lQsuclRQf-2w for ; Thu, 31 Dec 2009 08:55: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 D00443A6A37 for ; Thu, 31 Dec 2009 08:55: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 1NQOIJ-000C6L-UU; Thu, 31 Dec 2009 16:54:40 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E26F86678; Thu, 31 Dec 2009 16:54:37 +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: U2FsdGVkX19tm5Pz6vpQ0Dv0g1MCg0mFD7obcsuFVZI= Message-ID: <4B3CD74E.2050703@extendedsubset.com> Date: Thu, 31 Dec 2009 10:54:38 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tom.petch" References: <4B33F445.4010203@bolyard.me><4B33F7B4.3000101@pobox.com> <4B340609.9090008@bolyard.me> <051b01ca88a1$e6bc6920$0601a8c0@allison><4B3A82A1.6060503@bolyard.me> <4B3A890A.1040506@extendedsubset.com> <001b01ca89f4$30f57a60$0601a8c0@allison> In-Reply-To: <001b01ca89f4$30f57a60$0601a8c0@allison> X-Enigmail-Version: 0.96.0 OpenPGP: id=1E36DBF2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF TLS Working Group Subject: Re: [TLS] Naming that TLS session/connection instance thing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2009 16:55:03 -0000 tom.petch wrote: > From: "Marsh Ray" >> The goal was not to create a new thing, but to fix an existing thing. >> Perhaps we don't need to find new names, but standardize the existing >> usage. Hmmm, except that strangely there really wasn't much need to >> refer to an "instance of a session on a connection", so it never really >> developed a good term. > > But.... > The lengthy threads over the past eight weeks have tripped over the > lack of terminology several times No kidding. > and there has also been some consensus > that RFC5246 and its predecessors are not as easy to follow as they > might be for their use of session, connection, renegotiation, rehandshake,... My impression is that there are a variety of reasons for that. For example, many people have started to think about renegotiation and session resumption seriously for the first time and there is an inevitable learning curve. It may help to have a paragraph in the spec just reiterating the differences and some more detail in the glossary section. But at some point, the RFCs are standards documents, not tutorials. They needs to have the raw info that someone who's willing to invest months or years into the spec to implement it correctly. Too much redundant explanation tends to get in the way and runs the risk of introducing conflicting statements. The terms 'session', 'connection', and 'renegotiation' are adequately described. The term 'rehandshake' should probably be replaced with a more consistent term like 'renegotiation'. > (And I still think that there is an ambiguity in the I-D that I struggle > to communicate because of this lack). It would be good to get that figured out. We can follow up off list if you're concerned about the "DoS" on this list (as some have described it). > And Nico has said he wants > this clarified as part of channel binding suggesting that > "draft-altman-tls-channel-bindings, which defines (or soon will) the term ought > to update RFC5246" (3Dec09) With all due respect to the Channel Bindings work, we really really need the renegotiation fix to be considered separately. The CB activity has been going on for years and has a significant history. The RI fix has to be safe, effective, and shippable yesterday. > We already have thing1, thing2, thing3, ... we are not creating anything new, > we just do not have terms for them, which costs time in misunderstandings > and, perhaps, makes defects such as the current one harder to spot. > > For myself, I have litle concern as to what we call this if only we could > agree on a name; connection state would be fine (as would section, link...) . The problem I see with 'connection state' is it's current definition: > A TLS connection state is the operating environment of the TLS Record > Protocol. It specifies a compression algorithm, and encryption > algorithm, and a MAC algorithm. In addition, the parameters for > these algorithms are known: the MAC secret and the bulk encryption > keys for the connection in both the read and the write directions. > Logically, there are always four connection states outstanding: the > current read and write states, and the pending read and write states. > All records are processed under the current read and write states. This verbiage is necessary because it describes the operation of the protocol. Unfortunately, it doesn't really capture the idea of "an instance of a session on the connection". Maybe that's an inherently unclear notion due to the design of TLS. After all, an unlimited amount of data can be transferred while the client is in one connection state and the server is in another! > And then we should go on to agree a name for the thing that - with the fix - > survives renegotiations; etc. Nico may have Secure Channel lined up > for that. Everybody has always referred to that as a "TLS connection". - Marsh From djhopwood@googlemail.com Thu Dec 31 12:03: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 BEE783A67EE for ; Thu, 31 Dec 2009 12:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 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 sZpbA1mLLgXS for ; Thu, 31 Dec 2009 12:03: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 63B963A6824 for ; Thu, 31 Dec 2009 12:03:50 -0800 (PST) Received: by ewy6 with SMTP id 6so11749160ewy.29 for ; Thu, 31 Dec 2009 12:03: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=ZAdxtmAJJ9QAI66iFp8CSZDY24IUsC4vN/wzJ304JE0=; b=pfjgirfeyfbYQCHochNTMUYPuV/xb1ncXLWmZ4nApAp86ZYndfh5iIHkb3INBcTx6i hG6G03EcIZtwccpnScL3fPw9XM+hNXUfIMu90jvc3xV3+hIEfzbchsauurlIavNVBWGo jbzJRnEwfPRzqLCZq/Ywr7CD6Wbmnij4xPMW4= 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=K958J1dLkOox/GJRrgZ12rbjx+CHKMMMbqhV6YheAe2EQ+B/IEpmf4WBtCHqGh0cgW eXchIvagDJ4fCMV1SCQz9hjzG28uUCFI2mYxYniRhRDv9UjNu7PBuSVDKSyNx+h2X+wS VY0p74/xyAJAqS5BJgK979/X8EdfDbsn9eELk= Received: by 10.213.110.17 with SMTP id l17mr14559641ebp.91.1262289806868; Thu, 31 Dec 2009 12:03:26 -0800 (PST) Received: from ?192.168.0.2? (5e058d2d.bb.sky.com [94.5.141.45]) by mx.google.com with ESMTPS id 10sm30551919eyz.31.2009.12.31.12.03.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 31 Dec 2009 12:03:25 -0800 (PST) Sender: David-Sarah Hopwood Message-ID: <4B3D0388.7010709@jacaranda.org> Date: Thu, 31 Dec 2009 20:03: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: <3561bdcc0912302220t7fad9ccfqf5103e6f120288ba@mail.gmail.com> In-Reply-To: <3561bdcc0912302220t7fad9ccfqf5103e6f120288ba@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4BCA2B9A0647EBF853736CA1" Subject: Re: [TLS] renego, patricide, putting out to stud, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2009 20:03:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4BCA2B9A0647EBF853736CA1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ravi Ganesan wrote: >>> Ravi Ganesan wrote: >>> ii) A node can create a child node by performing renegotiation, follo= wed by >>> a full handshake. Such a full-renego-child, starts afresh with new va= lues >>> for all of the first five parameters. The only parameter which keeps = it tied >>> to this tree is the renegotiation-information, which is derived from = the >>> handshake and the parent-node's renegotiation-information. The primar= y >>> use-case for this technique is to update authentication-knowledge of= the >>> Server (i.e. does it know who the Client is?). The creation of such = a child >>> node means the parent node can no longer be used. >=20 >> That (the last sentence) is not the case, as far as I'm aware. Renegot= iating >> on some connection currently associated with a session does not mean t= hat >> that session can no longer be resumed. >=20 > What I meant by 'that node can no longer be used', is that since the > effective encryption/hashing keys have been rolled over, > trying to send data using the values in that node to the side should > not work. In that sense either of the renego child nodes renders its > parent inactive. OK, but that's a fairly complicated way of describing the semantics. Also= you used the term "session" to describe the nodes: # Treating each session as a node in a graph we can get a tree rooted at # the ROOT. which is not consistent with "that node can no longer be used", since the= *session* can be reused. Per connection, the progression of connection states is linear, not a tre= e, and that's the simplest way of describing it. --=20 David-Sarah Hopwood =E2=9A=A5 http://davidsarah.livejournal.com --------------enig4BCA2B9A0647EBF853736CA1 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/ iF4EAREIAAYFAks9A5UACgkQWUc8YzyzqAfJXwD/fQKDHA+0pjQLieSXaWDQnd/W 2RNWrDI51W+s/9/D6BoA/iBBcCvI3Efb1JMXw9HDVsZvETWBwC+VYTKyox6dDAdR =1ncB -----END PGP SIGNATURE----- --------------enig4BCA2B9A0647EBF853736CA1-- From ravi@findravi.com Thu Dec 31 15:43: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 19EF33A6917 for ; Thu, 31 Dec 2009 15:43:16 -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.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KW7sjiWR2U1z for ; Thu, 31 Dec 2009 15:43:14 -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 C05DB3A6919 for ; Thu, 31 Dec 2009 15:43:14 -0800 (PST) Received: by pwi20 with SMTP id 20so8813502pwi.29 for ; Thu, 31 Dec 2009 15:42:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.151.5 with SMTP id d5mr13755385wao.204.1262302970807; Thu, 31 Dec 2009 15:42:50 -0800 (PST) In-Reply-To: <4B3D0388.7010709@jacaranda.org> References: <3561bdcc0912302220t7fad9ccfqf5103e6f120288ba@mail.gmail.com> <4B3D0388.7010709@jacaranda.org> Date: Thu, 31 Dec 2009 15:42:50 -0800 Message-ID: <3561bdcc0912311542i1f2172c1na34e298d102d4408@mail.gmail.com> From: Ravi Ganesan To: David-Sarah Hopwood Content-Type: multipart/alternative; boundary=0016e64eeb642c84db047c0ed015 Cc: tls@ietf.org Subject: Re: [TLS] renego, patricide, putting out to stud, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2009 23:43:16 -0000 --0016e64eeb642c84db047c0ed015 Content-Type: text/plain; charset=UTF-8 >> OK, but that's a fairly complicated way of describing the semantics. Also >> you used the term "session" to describe the nodes: It is somewhat complicated, but I think it is the minimum needed. I just feel getting into connections, sessions, channels, all words which carry unintended baggage, does not seem to be working. Just consider if I am the Client and you are the Server, and we open a thingy (call it A) communicate for a while. Use A to spawn two more thingys in parallel using abbreviated handshakes (B and C). Then do a renego using full handshake on B (gives us D). D then spawns two more thingys using abbreviated handshakes (E and F). F happens to do a renego using a full handshakes to spawn G. In the meanwhile we do a full handshake renego on A, and then.... you are asked to explain in retrospect exactly what on earth happened. If you use my approach of tagging each of the nodes A,B,C,D,E, F and G with the six variables (session-id, master-secret, client-random, server-random, auth knowledge and RI), and show which of them change from parent to child, you will end up with a compact tree with the properties I mentioned. But of course I am biased, I feel it is limiting to use words that limit TLS to "sockets" or "connections", needlessly. For instance what does a connection mean if the binding is not TCP? e.g. EKR's work on UDP, mine on HTTP, Gajek et al on SOAP). This bias aside, however, I think the tree with its state transitions is useful even for regular TLS. Especially since we are keeping chained hashes around. Message: 1 > Date: Wed, 30 Dec 2009 16:46:49 -0800 > From: Ravi Ganesan > Subject: Re: [TLS] sessions, contexts, etc. > To: tls@ietf.org > Message-ID: > <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Does something along these lines work as a pedagogical device? Nodes > characterized by the parameters of relevance. A root node, three types of > ways to spawn a child node. What a child inherits from parent, etc... > > At the end of a TLS handshake, the Client and the Server share six key > pieces of information: > (i) a session-id /*Public information */ > (ii) a shared master-secret /*Secret. Known only to Client and Server */ > (iii) the client-random and /* May be public or secret */ > (iv) the server-random. /*May be public or secret*/ > (v) authentication knowledge /* Namely, the Client MAY know that is has > authenticated the Server (in practice this almost always is true). The > Server MAY know that it has authenticated the Client (relatively rare in > practice, but an important sub-category). > (vi) renegotiation-information /*The newly introduced RI field at the end > of > the handshake. */ > > > When the Client and a Server share NONE of the above six pieces of data, > the Client will typically initiate a completely fresh session using the > FULL > handshake. Such a session is called a ROOT session. A Client and a Server > who have completed a ROOT session can engage in further handshakes to > create > new sessions, which in turn can create further sessions. Treating each > session as a node in a graph we can get a tree rooted at the ROOT. > > Each node can spawn a child node using three different techniques as > follows: > > i) A node can create a child-node by performing an abbreviated handshake. > Such an abbreviated-child inherits the session-id, the shared master-secret > and the authentication-knowledge, from its parent (these CANNOT change). It > gets new client-random, server-random and starts afresh with > renegotiation-information. This technique of spawning a child node is > usually used for efficiency considerations (abbrv. handshake requires no > PKI > operations, which is why it cannot be used to update > authentication-knowledge of the other end either). The creation of such a > child-node does NOT result in the previous node becoming inactive. > > ii) A node can create a child node by performing renegotiation, followed by > a full handshake. Such a full-renego-child, starts afresh with new values > for all of the first five parameters. The only parameter which keeps it > tied > to this tree is the renegotiation-information, which is derived from the > handshake and the parent-node's renegotiation-information. The primary > use-case for this technique is to update authentication-knowledge of the > Server (i.e. does it know who the Client is?). The creation of such a > child > node means the parent node can no longer be used. > > iii) A node can create a child node by performing renegotiation followed by > an abbreviated handshake. Such a abbrv-renego-child inherits the > session-id, > shared-master-secret and authentication-information of its parent. There is > a new client-random and server-random, and as in a full-renego-child, the > renegotiation-information is derived from the handshake and the the > renegotiation-information of its parent. I do not know why this use-case > exists; the encryption/hashing keys change but it is questionable if that > adds any protection. The creation of such a child node means the parent > node > can no longer be used. > > Observe that each of the different child nodes can give birth to any of the > other three types of children. > > --0016e64eeb642c84db047c0ed015 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> OK, but that's a fairly complicated way of describing the sema= ntics. Also
>> you used the term "session" to describe the nodes:

It is somewhat complicated, but I think it is the minimum needed. I jus= t feel getting into connections, sessions, channels, all words which carry = unintended baggage, does not seem to be working.=C2=A0 Just consider if I a= m the Client and you are the Server, and we open a thingy (call it A) commu= nicate for a while. Use A to spawn two more thingys in parallel using abbre= viated handshakes (B and C). Then do a renego using full handshake on B (gi= ves us D). D then spawns two more thingys using abbreviated handshakes (E a= nd F). F happens to do a renego using a full handshakes to spawn G. In the = meanwhile we do a full handshake renego on A, and then.... you are asked to= explain in retrospect exactly what on earth happened. If you use my approa= ch of tagging each of the nodes A,B,C,D,E, F and G with the six variables (= session-id, master-secret, client-random, server-random, auth knowledge and= RI), and show which of them change from parent to child, you will end up w= ith a compact tree with the properties I mentioned.=C2=A0

But of course I am biased, I feel it is limiting to use words that limi= t TLS to "sockets" or "connections", needlessly.=C2=A0 = For instance=C2=A0 what does a connection mean if the binding is not TCP? e= .g.=C2=A0 EKR's work on UDP, mine on HTTP, Gajek et al on SOAP).
This bias aside, however, I think the tree with its state transitions is us= eful even for regular TLS. Especially since we are keeping chained hashes a= round.


Message: 1
Date: Wed, 30 Dec 2009 16:46:49 -0800
From: Ravi Ganesan <ravi@findravi.com>
Subject: Re: [TLS] sessions, contexts, etc.
To: tls@ietf.org
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0<3561bdcc0912301646p6592= 3143t1b138fb17b75d9@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Does something along these lines work as a pedagogical device? Nodes
characterized by the parameters of relevance. A root node, three types of ways to spawn a child node. What a child inherits from parent, etc...

At the end of a TLS handshake, the Client and the Server share six key
pieces of information:
(i) a session-id =C2=A0/*Public information */
(ii) a shared master-secret /*Secret. Known only to Client and Server */ (iii) the client-random and /* May be public or secret */
(iv) the server-random. =C2=A0/*May be public or secret*/
(v) authentication knowledge /* Namely, the Client MAY know that is has
authenticated the Server (in practice this almost always is true). The
Server MAY know that it has authenticated the Client (relatively rare in practice, but an important sub-category).
(vi) renegotiation-information /*The newly introduced RI field at the end o= f
the handshake. */


When the =C2=A0Client and a Server share NONE of the above six pieces of da= ta,
the Client will typically initiate a completely fresh session using the FUL= L
handshake. =C2=A0Such a session is called a ROOT session. A Client and a Se= rver
who have completed a ROOT session can engage in further handshakes to creat= e
new sessions, which in turn can create further sessions. Treating each
session as a node in a graph we can get a tree rooted at the ROOT.

Each node can spawn a child node using three different techniques as
follows:

i) A node can create a child-node by performing an abbreviated handshake. Such an abbreviated-child inherits the session-id, the shared master-secret=
and the authentication-knowledge, from its parent (these CANNOT change). It=
gets new client-random, server-random and starts afresh with
renegotiation-information. =C2=A0This technique of spawning a child node is=
usually used for efficiency considerations (abbrv. handshake requires no PK= I
operations, which is why it cannot be used to update
authentication-knowledge of the other end either). =C2=A0The creation of su= ch a
child-node does NOT result in the previous node becoming inactive.

ii) A node can create a child node by performing renegotiation, followed by=
a full handshake. Such a full-renego-child, starts afresh with new values for all of the first five parameters. The only parameter which keeps it tie= d
to this tree is the renegotiation-information, which is derived from the handshake and the parent-node's renegotiation-information. The primary<= br> use-case for this technique is =C2=A0to update authentication-knowledge of = the
Server (i.e. does it know who the Client is?). =C2=A0The creation of such a= child
node means the parent node can no longer be used.

iii) A node can create a child node by performing renegotiation followed by=
an abbreviated handshake. Such a abbrv-renego-child inherits the session-id= ,
shared-master-secret and authentication-information of its parent. There is=
a new client-random and server-random, and as in a full-renego-child, the renegotiation-information is derived from the handshake and the the
renegotiation-information of its parent. =C2=A0I do not know why this use-c= ase
exists; the encryption/hashing keys change but it is questionable if that adds any protection. The creation of such a child node means the parent nod= e
can no longer be used.

Observe that each of the different child nodes can give birth to any of the=
other three types of children.

--0016e64eeb642c84db047c0ed015-- From mike-list@pobox.com Thu Dec 31 17:17: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 0084D3A67BD for ; Thu, 31 Dec 2009 17:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFrjB74-xY6M for ; Thu, 31 Dec 2009 17:17: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 5F0CB3A6782 for ; Thu, 31 Dec 2009 17:17:17 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 36C338CD28 for ; Thu, 31 Dec 2009 20:16: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=BW2Q0jFkHnLg o54VTqYG6o6fYQ4=; b=cwx3HqcK4n4bS56tf+B2gDAN1gAl486IqbquoJHExHPH zoOQ+ChFYw3/BWxb8Z/lJNxJkCxsRPiO8RxgJxoGonCmpmVQf5Drp8x56roBEexU m8FQvMwxznnPx6zrvvtIhd0Fr5ApXvZmAJEYH3QPnD10iTx1KHOUJLKhgAfSwKU= 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=TsPWbt Bc8a6trkrZjANYX8is6vD05xMuaCsUddeL+zjnJUXDNbSOFeKRSCTKtEa+eoyi/z ts1anPyN0mBUIUGrwyfDQLImKg2rnCLx/s6Bo3Uro2DfJNyMv2n7+De5GMI17x5p uhNjAArCEeR0LIcUjN1N5iDPTKpDr0lFxhgVM= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 338A68CD27 for ; Thu, 31 Dec 2009 20:16: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-quonix.pobox.com (Postfix) with ESMTPSA id 8946F8CD26 for ; Thu, 31 Dec 2009 20:16:55 -0500 (EST) Message-ID: <4B3D4D8D.6030900@pobox.com> Date: Thu, 31 Dec 2009 17:19:09 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <3561bdcc0912302220t7fad9ccfqf5103e6f120288ba@mail.gmail.com> <4B3D0388.7010709@jacaranda.org> <3561bdcc0912311542i1f2172c1na34e298d102d4408@mail.gmail.com> In-Reply-To: <3561bdcc0912311542i1f2172c1na34e298d102d4408@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 5A254398-F673-11DE-835D-9D59EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] renego, patricide, putting out to stud, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 01 Jan 2010 01:17:20 -0000 It's not really parent-child, it is actually more like cloning and metamorphosis. Mike Ravi Ganesan wrote: > >> OK, but that's a fairly complicated way of describing the semantics. > Also > >> you used the term "session" to describe the nodes: > > It is somewhat complicated, but I think it is the minimum needed. I just > feel getting into connections, sessions, channels, all words which carry > unintended baggage, does not seem to be working. Just consider if I am > the Client and you are the Server, and we open a thingy (call it A) > communicate for a while. Use A to spawn two more thingys in parallel > using abbreviated handshakes (B and C). Then do a renego using full > handshake on B (gives us D). D then spawns two more thingys using > abbreviated handshakes (E and F). F happens to do a renego using a full > handshakes to spawn G. In the meanwhile we do a full handshake renego on > A, and then.... you are asked to explain in retrospect exactly what on > earth happened. If you use my approach of tagging each of the nodes > A,B,C,D,E, F and G with the six variables (session-id, master-secret, > client-random, server-random, auth knowledge and RI), and show which of > them change from parent to child, you will end up with a compact tree > with the properties I mentioned. > > But of course I am biased, I feel it is limiting to use words that limit > TLS to "sockets" or "connections", needlessly. For instance what does > a connection mean if the binding is not TCP? e.g. EKR's work on UDP, > mine on HTTP, Gajek et al on SOAP). > This bias aside, however, I think the tree with its state transitions is > useful even for regular TLS. Especially since we are keeping chained > hashes around. > > > Message: 1 > Date: Wed, 30 Dec 2009 16:46:49 -0800 > From: Ravi Ganesan > > Subject: Re: [TLS] sessions, contexts, etc. > To: tls@ietf.org > Message-ID: > <3561bdcc0912301646p65923143t1b138fb17b75d9@mail.gmail.com > > > Content-Type: text/plain; charset="utf-8" > > Does something along these lines work as a pedagogical device? Nodes > characterized by the parameters of relevance. A root node, three > types of > ways to spawn a child node. What a child inherits from parent, etc... > > At the end of a TLS handshake, the Client and the Server share six key > pieces of information: > (i) a session-id /*Public information */ > (ii) a shared master-secret /*Secret. Known only to Client and Server */ > (iii) the client-random and /* May be public or secret */ > (iv) the server-random. /*May be public or secret*/ > (v) authentication knowledge /* Namely, the Client MAY know that is has > authenticated the Server (in practice this almost always is true). The > Server MAY know that it has authenticated the Client (relatively rare in > practice, but an important sub-category). > (vi) renegotiation-information /*The newly introduced RI field at > the end of > the handshake. */ > > > When the Client and a Server share NONE of the above six pieces of > data, > the Client will typically initiate a completely fresh session using > the FULL > handshake. Such a session is called a ROOT session. A Client and a > Server > who have completed a ROOT session can engage in further handshakes > to create > new sessions, which in turn can create further sessions. Treating each > session as a node in a graph we can get a tree rooted at the ROOT. > > Each node can spawn a child node using three different techniques as > follows: > > i) A node can create a child-node by performing an abbreviated > handshake. > Such an abbreviated-child inherits the session-id, the shared > master-secret > and the authentication-knowledge, from its parent (these CANNOT > change). It > gets new client-random, server-random and starts afresh with > renegotiation-information. This technique of spawning a child node is > usually used for efficiency considerations (abbrv. handshake > requires no PKI > operations, which is why it cannot be used to update > authentication-knowledge of the other end either). The creation of > such a > child-node does NOT result in the previous node becoming inactive. > > ii) A node can create a child node by performing renegotiation, > followed by > a full handshake. Such a full-renego-child, starts afresh with new > values > for all of the first five parameters. The only parameter which keeps > it tied > to this tree is the renegotiation-information, which is derived from the > handshake and the parent-node's renegotiation-information. The primary > use-case for this technique is to update authentication-knowledge > of the > Server (i.e. does it know who the Client is?). The creation of such > a child > node means the parent node can no longer be used. > > iii) A node can create a child node by performing renegotiation > followed by > an abbreviated handshake. Such a abbrv-renego-child inherits the > session-id, > shared-master-secret and authentication-information of its parent. > There is > a new client-random and server-random, and as in a > full-renego-child, the > renegotiation-information is derived from the handshake and the the > renegotiation-information of its parent. I do not know why this > use-case > exists; the encryption/hashing keys change but it is questionable if > that > adds any protection. The creation of such a child node means the > parent node > can no longer be used. > > Observe that each of the different child nodes can give birth to any > of the > other three types of children. > > > ------------------------------------------------------------------------ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Thu Dec 31 17: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 4C12D3A686D for ; Thu, 31 Dec 2009 17:42:41 -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 qciF6a722q7O for ; Thu, 31 Dec 2009 17:42:40 -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 7DF0C3A680A for ; Thu, 31 Dec 2009 17:42:40 -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 1NQWWx-0008KT-Go; Fri, 01 Jan 2010 01:42:19 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 39BEF6678; Fri, 1 Jan 2010 01:42:18 +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+xK8m3Yf7fVSgY03nb+Qf6wYQNWQ4FwR4= Message-ID: <4B3D52FA.3050607@extendedsubset.com> Date: Thu, 31 Dec 2009 19:42:18 -0600 From: Marsh Ray User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ravi Ganesan References: <3561bdcc0912302220t7fad9ccfqf5103e6f120288ba@mail.gmail.com> <4B3D0388.7010709@jacaranda.org> <3561bdcc0912311542i1f2172c1na34e298d102d4408@mail.gmail.com> In-Reply-To: <3561bdcc0912311542i1f2172c1na34e298d102d4408@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] renego, patricide, putting out to stud, etc. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 01 Jan 2010 01:42:41 -0000 Ravi Ganesan wrote: > > [...] > > But of course I am biased, I feel it is limiting to use words that limit > TLS to "sockets" or "connections", needlessly. The TLS spec doesn't use the term "socket" anywhere. > For instance what does > a connection mean if the binding is not TCP? A TLS connection is pretty fundamental. >From the application layer's perspective, the connection is a conduit through which it may send and receive application data with the benefit of the security guarantees of TLS. At the TLS record layer, a connection is a sequence of TLS records with consistent framing, record sequence numbers, MAC and crypto params. TLS needs to ride on some reliable and ordered transport, but it doesn't have to be TCP. A few places in the TLS spec say certain errors must "terminate the connection", but it can't really mandate the behavior of lower levels. (E.g., an application using starttls could drop back to the unencrypted protocol rather than actually closing the TCP connection). - Marsh