From ynir@checkpoint.com Mon Aug 1 00:16:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3331721F8548 for ; Mon, 1 Aug 2011 00:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hmmrd-ujC6m for ; Mon, 1 Aug 2011 00:16:11 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF7521F853E for ; Mon, 1 Aug 2011 00:16:10 -0700 (PDT) X-CheckPoint: {4E366047-8-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p717G0Ge028225; Mon, 1 Aug 2011 10:16:00 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 1 Aug 2011 10:16:00 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 1 Aug 2011 10:16:00 +0300 From: Yoav Nir To: Marsh Ray , David McGrew Date: Mon, 1 Aug 2011 10:15:59 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxQGt1e/bSJMaKCSNKc2kOs42RMRg== Message-ID: In-Reply-To: <4E364790.3000305@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pgladstone@cisco.com" , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 07:16:12 -0000 On 8/1/11 9:28 AM, "Marsh Ray" wrote: > >> The intent of the authors is to enable TLS to be >> used when an proxy is present, > >But the intent of TLS is to prevent man-in-the-middle attacks, i.e., to >prevent you from proxying it. > >Just because you can exploit it almost reliably with a custom root CA on >today's clients doesn't mean that it's not deeply contrary to the >security architecture of TLS. > >Design a secure way for the legitimate endpoints to agree to share some >session key material with you in a way that doesn't impersonate anyone. >I might even support such an extension (but good luck convincing the >servers of the world). Actually, with this extension, the proxy does not need to generate a "fake certificate". It's fine for the proxy to present a certificate for "CN=3Dtlsproxy.example.com" and convey the real certificate in the extension. Of course, clients would have to explicitly trust the proxy, but that can be added as part of adding support for the extension. As for servers, it's possible to change the tls-proxy format in ClientHello to have a "role" field that could be either "client" or "proxy". Then the servers would be able to reject connections from proxies. Would that make it more acceptable? > >> and to make clients informed about both >> the proxy and the server, and to provide cryptographically strong >> authentication of both. > >This concept of polyamorous TLS is more radical than its proponents want >to accept. Practically, I don't see this happening. The IETF generally does not radically alter protocols to fit the needs of middleboxes, it's the middleboxes that have to adapt at least at first. Later we do see how the active mode of FTP replaces the passive mode because it fits NAT better. From mcgrew@cisco.com Mon Aug 1 05:25:49 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C0711E814A for ; Mon, 1 Aug 2011 05:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shY+aUo7VaDN for ; Mon, 1 Aug 2011 05:25:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 01DCB11E816C for ; Mon, 1 Aug 2011 05:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=5486; q=dns/txt; s=iport; t=1312201555; x=1313411155; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=FGkMZ+otAwX4uXcPL4yw4jZXiq2J86L7TKXSMfP5yFM=; b=dch0GAnL13SRm6h1/ME/ppp15WSxOiZhchqKeCKd6ShkSR9XOBH2QprP eEz4a+oIVHW267g09tqbdSGFOCVmSqdlqccq4y05xIqPbuHjYiugL+MHs FH+l6X2ZoSae1anyFoQakRUex9WOu3IoO8G6COMFsyp8/15nm8uF2EMy/ 4=; X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8410362" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2011 12:25:55 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71CPrDd026305; Mon, 1 Aug 2011 12:25:53 GMT Message-Id: <7064FD6B-D0E4-44A5-B794-FA31F5A2CCC2@cisco.com> From: David McGrew To: Marsh Ray In-Reply-To: <4E364790.3000305@extendedsubset.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Aug 2011 05:25:52 -0700 References: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> <4E337BF4.8030307@extendedsubset.com> <145F5A54-7702-4C82-BB39-C630E02E1A99@cisco.com> <4E364790.3000305@extendedsubset.com> X-Mailer: Apple Mail (2.936) Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:25:49 -0000 Again, it seems that you do not quite understand what we are trying to achieve. There is current practice that uses proxies in a way that is bad for clients (and you outline many of the reasons below). We aim to improve the situation for clients and the security of the overall solution. One important point: it is possible to design a solution in which the proxy does not contain a CA. Propagating TLS session key material is a worse idea for a lot of reasons. It would be a fragile solution in which easy-to-make implementation mistakes could undermine security. It would require considerable new implementation work. It would make crypto validation considerably harder if not impossible. If it aimed to preserve end- to-end authentication, it would be fundamentally incompatible with Authenticated Encryption in general and the AEAD facility in TSL 1.2 in particular, and it would probably end up getting misused and abused in practice. If it did not aim to preserve end-to-end authentication, then it would require considerable changes to the TLS protocol, to prevent keystream insertion attacks and keystream re-use. Perhaps worst of all, it would create a mechanism that could more easily be abused; a server could (mis)use it and give away session keys without the knowledge or consent of the client. I will work to make the next version of the draft more clear and more complete. David On Jul 31, 2011, at 11:28 PM, Marsh Ray wrote: > On 07/30/2011 08:20 AM, David McGrew wrote: >> It seems that you do not understand the intent of the draft or the >> authors. > > The intent is nearly irrelevent. The text of the spec and the bits > on the wire are what matters. > >> The use case here is web filtering as it is used by organizations and >> consumers, in which a consumer or an organization chooses to use a >> service or a product that acts as an HTTP proxy, and configures their >> clients to do so. It is desirable in such cases to use TLS whenever >> possible, and it is certainly desirable that the client be able to >> authenticate the proxy. > > HTTP has explicit support for proxies and you can connect to them > securely via TLS already. Wouldn't this all be done more > appropriately at the HTTP layer? > >> The intent of the authors is to enable TLS to be >> used when an proxy is present, > > But the intent of TLS is to prevent man-in-the-middle attacks, i.e., > to prevent you from proxying it. > > Just because you can exploit it almost reliably with a custom root > CA on today's clients doesn't mean that it's not deeply contrary to > the security architecture of TLS. > > Design a secure way for the legitimate endpoints to agree to share > some session key material with you in a way that doesn't impersonate > anyone. I might even support such an extension (but good luck > convincing the servers of the world). > >> and to make clients informed about both >> the proxy and the server, and to provide cryptographically strong >> authentication of both. > > This concept of polyamorous TLS is more radical than its proponents > want to accept. > > Current TLS: > Client strongly authenticates server via trusted CA > Server may authenticate client, but usually server relies on client > to stop S-C MitM > Any proxy can only slow or drop connections > > "TLS proxy" via root cert on client: > Client can't authenticate server any stronger than weakest proxy > allows > Client may not even be aware of proxies > Any proxy may degrade security of connections arbitrarily > Any proxy may get pwned and expose its root CA private key > Any proxy may prevent the use of protocol features and extensions > Any proxy can both read and modify plaintext > Server can't authenticate client at all, client certs are busted > forever > Server can't authenticate proxy at all > Server probably can't detect proxy downgrade > Proxy relies on client to stop P-C MitM > Server relies on proxy to stop S-P MitM > >> The client should be able to decide if it >> accepts the proxy for a particular session, and the scope of the >> proxy >> should be limited, and the proxy should not lie to the client. The >> client should also have the full information about the server on the >> other end of the connection. > > But by installing the custom root CA in the browser you've weakened > the guarantees (which derive from "MUST"s and "MUST NOT"s) to merely > "should"s and "should not"s. I.e., you've removed the strong crypto > guarantees from the perspective of the legitimate client and (by > extension) the server, who are the only parties given any security > guarantees at all in the current TLS RFCs. > >> We oppose the development of a technology that would help a country >> spy >> on its citizens,and we certainly oppose the development of >> standards in >> that area. > > Meh. It already exists for anyone controlling a trusted root or sub- > CA, why would they choose to turn on this functionality? > >> The IETF can't control how the technologies that it develops >> are used, or who uses them, of course, which makes it imperative to >> not >> develop any mechanisms that could be used in that way. > > Put it another way: don't develop mechanisms that break basic > security guarantees. Even better would be to improve on them. > > - Marsh From mcgrew@cisco.com Mon Aug 1 05:32:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CCB11E8251 for ; Mon, 1 Aug 2011 05:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aanKqPPsg7II for ; Mon, 1 Aug 2011 05:32:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 36A5411E822F for ; Mon, 1 Aug 2011 05:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2285; q=dns/txt; s=iport; t=1312201937; x=1313411537; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=7hpsVk/Xcs88Sw97gJBeW/sH2gZcozWX0bo1jLO/f2Y=; b=VIi8rmP3fWbxmOgFBjCI5gY8BJ7fLV1weP7159h9RnD92WO709Hnrqy0 XqeKD1NU85n7KoEywRNFlyWaSrhfPrV0yYtdmGzF5AO6yHZxDfbl/XCQg O0DjZTo91sD+WqERd9NWP4hmvh+074hQT2BByODz/FQ8gjnGhLIfpob3D 8=; X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="105992204" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2011 12:32:14 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p71CWBFF028329; Mon, 1 Aug 2011 12:32:12 GMT Message-Id: From: David McGrew To: Yoav Nir In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Aug 2011 05:32:11 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "pgladstone@cisco.com" , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:32:12 -0000 On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote: > > > On 8/1/11 9:28 AM, "Marsh Ray" wrote: > >> >>> The intent of the authors is to enable TLS to be >>> used when an proxy is present, >> >> But the intent of TLS is to prevent man-in-the-middle attacks, >> i.e., to >> prevent you from proxying it. >> >> Just because you can exploit it almost reliably with a custom root >> CA on >> today's clients doesn't mean that it's not deeply contrary to the >> security architecture of TLS. >> >> Design a secure way for the legitimate endpoints to agree to share >> some >> session key material with you in a way that doesn't impersonate >> anyone. >> I might even support such an extension (but good luck convincing the >> servers of the world). > > Actually, with this extension, the proxy does not need to generate a > "fake > certificate". It's fine for the proxy to present a certificate for > "CN=tlsproxy.example.com" and convey the real certificate in the > extension. Of course, clients would have to explicitly trust the > proxy, > but that can be added as part of adding support for the extension. Agreed. It may also be desirable to add an authorization attribute to the certificate to explicitly label it as a proxy certificate. > > As for servers, it's possible to change the tls-proxy format in > ClientHello to have a "role" field that could be either "client" or > "proxy". Then the servers would be able to reject connections from > proxies. Would that make it more acceptable? This is a good idea. It does not provide strong authentication of who the proxy is, but it does inform about its presence. David > >> >>> and to make clients informed about both >>> the proxy and the server, and to provide cryptographically strong >>> authentication of both. >> >> This concept of polyamorous TLS is more radical than its proponents >> want >> to accept. > > Practically, I don't see this happening. The IETF generally does not > radically alter protocols to fit the needs of middleboxes, it's the > middleboxes that have to adapt at least at first. Later we do see > how the > active mode of FTP replaces the passive mode because it fits NAT > better. > > From mcgrew@cisco.com Mon Aug 1 07:19:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024BE21F8C57 for ; Mon, 1 Aug 2011 07:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.741 X-Spam-Level: X-Spam-Status: No, score=-102.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWy3MqjWNRUW for ; Mon, 1 Aug 2011 07:19:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1BF21F8C4D for ; Mon, 1 Aug 2011 07:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=688; q=dns/txt; s=iport; t=1312208349; x=1313417949; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=eXN9hqYZ0NaZ+0rV0R/YV4wavatTgQOsJ4nji2e3Jq4=; b=jBuJ6qGVkfmQjT13QOA6UOryR+hzvUUzzOWgIiLOeRQpYd5ScPM4+FoQ aEF333Inm9XTTrL7b5KtT2UWYWLNE78Smokd0snnkoKccpgtbGtdh6lJo uyzyW9hyFjTjBMPNnELRVNEc/GI3HnDHvWAFjn2yqP3UNM+JBWdmVF75e o=; X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208";a="8446433" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2011 14:19:08 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71EJ7X4023810; Mon, 1 Aug 2011 14:19:07 GMT Message-Id: From: David McGrew To: Yoav Nir In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Aug 2011 07:19:08 -0700 References: X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:19:03 -0000 On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote: > > > As for servers, it's possible to change the tls-proxy format in > ClientHello to have a "role" field that could be either "client" or > "proxy". a further thought in this direction. The server could sign the extension that it gets from the proxy, and that signature could be returned to the client, along with the data that was signed. This would give the client a strong confirmation that the server was aware of the proxy. From a security standpoint, this is good. From a deployability standpoint, it would require that servers are modified to understand the extension, which is not so good. David From ynir@checkpoint.com Mon Aug 1 08:08:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F342D11E80C7 for ; Mon, 1 Aug 2011 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGZr9T5lD2ri for ; Mon, 1 Aug 2011 08:08:08 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BECB411E80B2 for ; Mon, 1 Aug 2011 08:08:07 -0700 (PDT) X-CheckPoint: {4E36CEE5-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p71F89JY000896; Mon, 1 Aug 2011 18:08:09 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 1 Aug 2011 18:08:10 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 1 Aug 2011 18:08:09 +0300 From: Yoav Nir To: David McGrew Date: Mon, 1 Aug 2011 18:08:17 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxQXNL3ArgYUtkXQRyKmg1zfBYong== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Philip Gladstone , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:08:09 -0000 On 8/1/11 5:19 PM, "David McGrew" wrote: > >On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote: >> >> >> As for servers, it's possible to change the tls-proxy format in >> ClientHello to have a "role" field that could be either "client" or >> "proxy". > >a further thought in this direction. The server could sign the >extension that it gets from the proxy, and that signature could be >returned to the client, along with the data that was signed. This >would give the client a strong confirmation that the server was aware >of the proxy. From a security standpoint, this is good. From a >deployability standpoint, it would require that servers are modified >to understand the extension, which is not so good. That depends on what the clients do with this strong confirmation. For example, I can see them showing the regular padlock even without the signature, but displaying the EV indication only when they get it. I'm also thinking about whether we can get client certificates to work. The hard problem is that Certificate Verify signs the handshake messages, and those are not available to the client. I don't think we want to send all the previous handshake messages in the extension, so getting this to work would also require a server-side change. Yoav From marsh@extendedsubset.com Mon Aug 1 08:28:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDF211E80DF for ; Mon, 1 Aug 2011 08:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNXP26hBW34d for ; Mon, 1 Aug 2011 08:28:05 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5911E8094 for ; Mon, 1 Aug 2011 08:28:05 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QnuPa-000J6I-Ek; Mon, 01 Aug 2011 15:28:10 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 02CDF606E; Mon, 1 Aug 2011 15:28: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+IDJ+5KrcLfHk1eLmhIZ0OXhO6bablovw= Message-ID: <4E36C607.4040504@extendedsubset.com> Date: Mon, 01 Aug 2011 10:28:07 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Philip Gladstone , David McGrew , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:28:05 -0000 On 08/01/2011 10:08 AM, Yoav Nir wrote: > > I'm also thinking about whether we can get client certificates to work. > The hard problem is that Certificate Verify signs the handshake messages, > and those are not available to the client. I don't think we want to send > all the previous handshake messages in the extension, so getting this to > work would also require a server-side change. You could just send the MD5/SHA-1/SHA-256 hashes of the messages, which is what the client cert signs. Of course, this amounts to the client being willing to sign basically anything for the proxy, carte blanche. If the client's cert were valid for other things such as serving TLS or code signing that could represent a significant escalation of privilege. - Marsh From mrex@sap.com Mon Aug 1 09:15:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DD511E80FB for ; Mon, 1 Aug 2011 09:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjNvfuYXAI7j for ; Mon, 1 Aug 2011 09:15:18 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0111E8077 for ; Mon, 1 Aug 2011 09:15:18 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p71GFGYe008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 18:15:16 +0200 (MEST) From: Martin Rex Message-Id: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> To: mcgrew@cisco.com (David McGrew) Date: Mon, 1 Aug 2011 18:15:16 +0200 (MEST) In-Reply-To: <7064FD6B-D0E4-44A5-B794-FA31F5A2CCC2@cisco.com> from "David McGrew" at Aug 1, 11 05:25:52 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:15:19 -0000 David McGrew wrote: > > Again, it seems that you do not quite understand what we are trying to > achieve. There is current practice that uses proxies in a way that > is bad for clients (and you outline many of the reasons below). We > aim to improve the situation for clients and the security of the > overall solution. One important point: it is possible to design a > solution in which the proxy does not contain a CA. You're trying to give the proxy the authority to impersonate _every_ server. Whether it is through an super-CA-cert or whether you're extending the protocol so that the client believes a forwarded certificate with _no_ proof-of-posession for that cert is a mere implementation detail, and has no impact of the size of the security problem that you want to newly create. > > Propagating TLS session key material is a worse idea for a lot of > reasons. It would be a fragile solution in which easy-to-make > implementation mistakes could undermine security. I'm sorry, but that is a completely bogus claim. If the proxy is terminating both TLS connections, it will have access to traffic encryption and mac keys of both connections can can leak those just as easily. Sharing the traffic encryption keys will not make this any worse. > > It would require considerable new implementation work. You mean because it would require an additional network channel to talk to the proxy? yes. It can not happen "by accident". > > It would make crypto validation considerably harder if not impossible. Nope. That is orthogonal. > > If it aimed to preserve end-to-end authentication, it would be > fundamentally incompatible with Authenticated Encryption in general > and the AEAD facility in TSL 1.2 in particular, and it would probably > end up getting misused and abused in practice. Correct, the use of AEAD would break the security, since this mode does not use seperate traffic encryption and mac keys. Personally, I consider AEAD a bad idea, so I don't mind disabling these cipher suites when traversing such a proxy. > > If it did not aim to preserve end-to-end authentication, > then it would require considerable changes to the TLS protocol, to > prevent keystream insertion attacks and keystream re-use. Perhaps > worst of all, it would create a mechanism that could more easily be > abused; a server could (mis)use it and give away session keys without > the knowledge or consent of the client. I have no clue what you mean. If the proxy terminates the clients TLS connection and establishes a new connection to the real server, then it will have to impersonate the real server to the client in any case and will always have all keying material available to do anything bad to either or both peers. So security-wise, the TLS proxy that you are proposing is at the far end of badness, there is _nothing_ that can possibly be worse, but a few thinghs might be *MUCH* better. -Martin From mrex@sap.com Mon Aug 1 09:28:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6721F8E07 for ; Mon, 1 Aug 2011 09:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.921 X-Spam-Level: X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z70bycwv04Hq for ; Mon, 1 Aug 2011 09:28:12 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C8B9B21F8E29 for ; Mon, 1 Aug 2011 09:28:11 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p71GSEnQ012513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 18:28:14 +0200 (MEST) From: Martin Rex Message-Id: <201108011628.p71GSCPm020409@fs4113.wdf.sap.corp> To: mcgrew@cisco.com (David McGrew) Date: Mon, 1 Aug 2011 18:28:12 +0200 (MEST) In-Reply-To: <145F5A54-7702-4C82-BB39-C630E02E1A99@cisco.com> from "David McGrew" at Jul 30, 11 06:20:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:28:12 -0000 David McGrew wrote: > > We oppose the development of a technology that would help a country > spy on its citizens, and we certainly oppose the development of > standards in that area. There is no fundamental difference between a country spying on citizens and a company spying on employees. Our constitution does not make a difference between these two (but admittely, some lower courts haven't grasped the legally binding constitutional court decisions yet). -Martin From mrex@sap.com Mon Aug 1 09:50:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87A721F8EE6 for ; Mon, 1 Aug 2011 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.925 X-Spam-Level: X-Spam-Status: No, score=-9.925 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec9xuJgyJbzN for ; Mon, 1 Aug 2011 09:50:45 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9FA21F8EE8 for ; Mon, 1 Aug 2011 09:50:41 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p71GocoL015014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 18:50:43 +0200 (MEST) From: Martin Rex Message-Id: <201108011650.p71Goc7j021785@fs4113.wdf.sap.corp> To: mcgrew@cisco.com (David McGrew) Date: Mon, 1 Aug 2011 18:50:38 +0200 (MEST) In-Reply-To: from "David McGrew" at Jul 30, 11 06:22:22 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, pgladstone@cisco.com Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:50:45 -0000 David McGrew wrote: > > > > > Cryptographic security of the TLS protocol is clearly unaffected > > from sharing the traffic encryption keys with the proxy. > > It would be an exceedingly brittle solution to build a system that > would be cryptographically insecure if proxies added or changed a > single byte, then insist and hope that proxies never modify the data > stream. Full agreement. Adding a client-side proxy into TLS authentication that terminates the clients SSL connection would be an extremely brittle solution and an unconditionally bad idea. > > > What happens is that the proxy may remove confidentiality of the > > data and look at the data before passing along the original, encrypted > > data the the rightful communication peer. > > > > It is a design property of the TLS protocol that having access > > to the traffic encryption keys does not allow _you_ to subvert other > > characteristics of the protocol beyond the confidentiality. > > That property does not hold for any use of authenticated encryption, > including that of RFC 5288 or the two drafts using CCM. Which means that security-wise those cipher suites are substantially weaker than tls cipher suites which provide encryption and integrity by independent means. Such cipher suites should not be enabled by default unless without considering the security impact for the usage scenario / environment where they should be used. > > >> A malware-screening proxy needs to be able to modify the traffic > >> flowing through it. It would be pointless for it to detect malware, > >> and then pass it on to the client! > > > > Huh? The peer does not get anything that the proxy does not forward. > > And if there is something goofy. the proxy simply terminates the > > connection (both connection. that to the real server and that to the > > real client). > > What I have been told is that there are proxies that don't work that > way, and it is not realistic to expect them to work that way. Rather > than debate that point on the list, let's seek out some objective data. Would you prefer to document instead what current proxies are doing and have the IETF rubber stamp that surveillance/wirtap techology as a standard? > > > For the purpose of malware screening, the proxy having only the > > traffic > > encryption keys is perfectly sufficient. And because it is perfectly > > sufficient, the MAC keys fall under constitutional protection and > > requesting them would be unlawful. > > Not using end-to-end message authentication is unconstitutional? > But decryption in the middle is OK? It would only be OK for the limited purpose where the central malware scanner works as an agent under direction and control of the client only (no central reporting, no company policy) as an alternative solution to having the client process the data locally as it leaves the TLS tunnel. -Martin > > If I rushed to conclusions on this topic, I might think that we are > violating the constitution because we haven't signed our emails with > SMIME or PGP. That can't be right, so apparently a more detailed > analysis is needed. Our consitutional protections (for communication privacy) are independent from what technical measures you employ to ensure privacy. They apply to cleartext communcation as well. Central scanning of EMails for malware is commonplace, but it can scan only non-encrypted EMails. TLS was designed to be secure end-to-end. And you're trying to take characteristic away from TLS by trying make the IETF standardize wiretapping/surveillance technology for TLS? I strongly dislike the idea. There is technology similar to what you're proposing as TLS proxy on the market and sold for the purpose of allegedly lawful intercept of HTTPS/TLS traffic. NO, I don't want the IETF to publish RFCs on what these boxes look like. Instead, we're actively working in the DANE working group on solutions to break any such gear that exploits the weaknesses in the (lack-of) trust model of the TLS X.509 PKI. -Martin From ietfc@btconnect.com Mon Aug 1 10:00:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677F411E8077 for ; Mon, 1 Aug 2011 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYAxeSQVBn2f for ; Mon, 1 Aug 2011 10:00:53 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7B11E80AB for ; Mon, 1 Aug 2011 10:00:52 -0700 (PDT) Received: from host109-153-78-164.range109-153.btcentralplus.com (HELO pc6) ([109.153.78.164]) by c2bthomr14.btconnect.com with SMTP id DVJ88264; Mon, 01 Aug 2011 18:00:48 +0100 (BST) Message-ID: <054c01cc5063$bcda28a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Eric Rescorla" , References: Date: Mon, 1 Aug 2011 17:57:34 +0200 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 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E36DBBF.0066, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.1.155415:17:7.586, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E36DBCA.0004,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [TLS] Setting Policy for Extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:00:54 -0000 I am unclear where this is going to go, such that those with an interest in it, in proposing or reviewing extensions, know that it exists and can access it. We have I-Ds, RFCs, we have a Charter and .... Where can it go? (If it belongs in an RFC, then it should have gone into RFC5246:-( Also, I think that it should contain a sunset clause, that is that whatever we agree on applies as long as there is a TLS WG, and that the topic must be revisited if and when the TLS WG is shut down - I do not think that the TLS WG should legislate for when it has ceased to exist:-) On a practical point, I would like the IETF LC to have a minimum period, say 8 weeks. Independent Submissions are sometimes slipped through with a Last Call of two weeks, which, I believe, has been insufficient for the IETF to review an I-D adequately (cannot recall a specific example but I can remember thinking it on a number of occasions). Tom Petch ----- Original Message ----- From: "Eric Rescorla" To: Sent: Wednesday, July 27, 2011 4:33 PM Subject: [TLS] Setting Policy for Extensions > TLS WG members, > > The WG is starting to see an increasing number of proposals for new > extensions, and it seems like it would be good to have a consistent > policy for how to handle these. The chairs have gotten together with > our AD and converged on the following draft policy, which we plan > to discuss in the " Working Group Handling for Extensions to TLS" > slot. > > Comments? > -Ekr > > [For Joe and Eric] > > > > RFC 5246 defines an extensibility mechanism for TLS based on > extensions signaled in the ClientHello and ServerHello. With TLS 1.2 > and DTLS 1.2 being relatively stable, we are starting to see more > proposed extensions, some of which, if used, represent significant > changes to the TLS state machine. RFC 5246 requires IETF consensus > for any extension. As there is an active TLS WG, this implies that > extensions must be vetted with that WG. The following policy > describes the level of review necessary for various types of > proposed extension: > > 1. All extensions to TLS (including AD sponsored extensions) must > minimally be sent explicitly to the TLS WG prior to or during IETF LC. > If that process surfaces significant objections, then these objections > should be resolved prior to publication. For trivial extensions, this > process is sufficient. An example of a trivial extension would be > signaling for a new TLS Exporter (RFC 5705), as this has no impact on > TLS proper. > > 2. All non-trivial extensions (i.e., anything which alters TLS > processing in some way) must be presented to the TLS WG and at least > be considered unobjectionable. They need not be WG items. Extensions > in this category can proceed without widespread WG support, but must > either have no significant objections or achieve WG consensus to > proceed. An example of a non-trivial extension would be one that > defined a new form of MAC truncation. This alters TLS processing but > not the state machine. > > 3. Extensions which which involve significant changes to the TLS > model/state machine, adds new messages, etc. must be TLS WG work > items, or, if primarily designed for some other WG, must be work items > of that WG and developed in collaboration with the TLS WG and subject > to the WG consensus process. Extensions in this category will > generally need to show significant amounts of non-author support in > order to proceed. Particular attention will be paid to the impact of > such extensions on the TLS architecture and the impact on potential > future extensions. An example of such an extension would be TLS > Tickets (RFC 4507), because it involved redoing the resumption state > machine and adding a new TLS message. > > > The WG considers it an important objective to to provide timely, > clear dispositions of new efforts. Work will be taken on when there is > consensus and based on the WG's estimate of the level of interest and > the size and priority of the current workload. Reconsideration of > proposals which have failed to gather consensus will be prioritized > behind proposals for new work which have not yet been considered. > In general, requests for reconsideration should only be made once a > proposal has been significantly revised and there is evidence of > substantial level of community support. > > > Best, > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mcgrew@cisco.com Mon Aug 1 12:15:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBB221F8DAE for ; Mon, 1 Aug 2011 12:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 259+oXusyZOf for ; Mon, 1 Aug 2011 12:15:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 96D1C21F8D9A for ; Mon, 1 Aug 2011 12:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=7524; q=dns/txt; s=iport; t=1312226124; x=1313435724; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=kLD2HClYzxX6mSetSxpTNm0dSlKilnJhHLqfAM8hpCA=; b=Hyd2hJBk5knocXSMzvdf86lu0fKholWjgcFbCKRrVM+FUOvpJqtDbv/D kTSFh/7kBO+8QNQm19FBegIHBblKkeJps4JVwqj8C8dCp4MiHe9Ctq0kz FjgwX76EfkuIaw1tCjb+wWFIDYO/cRgHmD8+ccCa3jBjx1M9u5voAkmOS M=; X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8541516" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2011 19:15:23 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p71JFL2G008211; Mon, 1 Aug 2011 19:15:22 GMT Message-Id: <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> From: David McGrew To: mrex@sap.com In-Reply-To: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Aug 2011 12:15:22 -0700 References: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:15:17 -0000 On Aug 1, 2011, at 9:15 AM, Martin Rex wrote: > David McGrew wrote: >> >> Again, it seems that you do not quite understand what we are trying >> to >> achieve. There is current practice that uses proxies in a way that >> is bad for clients (and you outline many of the reasons below). We >> aim to improve the situation for clients and the security of the >> overall solution. One important point: it is possible to design a >> solution in which the proxy does not contain a CA. > > You're trying to give the proxy the authority to impersonate > _every_ server. On the contrary, the goal here is to not have the proxy impersonate any other device, at least not impersonate in the cryptographic sense. > Whether it is through an super-CA-cert or whether > you're extending the protocol so that the client believes a forwarded > certificate with _no_ proof-of-posession for that cert is a mere > implementation detail, and has no impact of the size of the security > problem that you want to newly create. > It's hard to parse that sentence, but if I understand you right, you think that it is important for the client to have a strong assurance that the subject of the server certificate is an active participant in the session. I agree that is a highly desirable property. I think the right theoretical approach to analyzing this sort of protocol would be to start with a formal model of TLS as a two-party authentication protocol, and extend it to accomodate a three-party system with the appropriate role definitions. Fortunately, only the authentication aspects need to be considered, and some of the key establishment goals can be ignored, which makes the analysis easier. If we had the freedom to design the system from scratch, the obvious approach would be to have C, S, and P each issue nonces that get signed by each other party, along with the other data that gets currently signed, and indication of the role of each signer. What is most interesting is: how close can one get to this ideal protocol by extending TLS? > >> >> Propagating TLS session key material is a worse idea for a lot of >> reasons. It would be a fragile solution in which easy-to-make >> implementation mistakes could undermine security. > > I'm sorry, but that is a completely bogus claim. > > If the proxy is terminating both TLS connections, it will have access > to traffic encryption and mac keys of both connections can can leak > those just as easily. Sharing the traffic encryption keys will not > make this any worse. > > >> >> It would require considerable new implementation work. > > You mean because it would require an additional network channel to > talk to the proxy? yes. It can not happen "by accident". > > >> >> It would make crypto validation considerably harder if not >> impossible. > > Nope. That is orthogonal. On the above three points: allowing a proxy to coordinate betwen two TLS sessions allows one to preserve most of the TLS protocol and implementation. In contrast, a solution that propagates session keys will require new implementation work for the data plane, state management, and so on. If the proxy attempts to modify the session, all sorts of significant crypto problems will crop up. There will be HTTP proxies that expect to modify the traffic, and it would be unwise to expect that a proxy implementer would respect the injunction to not modify the session, if a specification for session key propagation were developed. It seems like a major difference that we have is that you expect a "read only" solution to be viable, while I don't. A read-only decryption proxy would be considerably easier to implement correctly. However, I have zero confidence that a read-only decryption proxy would not evolve into a read/write proxy, which would introduce very significant security problems. > > >> >> If it aimed to preserve end-to-end authentication, it would be >> fundamentally incompatible with Authenticated Encryption in general >> and the AEAD facility in TSL 1.2 in particular, and it would probably >> end up getting misused and abused in practice. > > Correct, the use of AEAD would break the security, since this mode > does > not use seperate traffic encryption and mac keys. Personally, I > consider > AEAD a bad idea, so I don't mind disabling these cipher suites when > traversing such a proxy. > Your personal opinion on AEAD goes against a lot of theory and standards work of the last decade. Have you considered providing your criticisms in writing? > >> >> If it did not aim to preserve end-to-end authentication, >> then it would require considerable changes to the TLS protocol, to >> prevent keystream insertion attacks and keystream re-use. Perhaps >> worst of all, it would create a mechanism that could more easily be >> abused; a server could (mis)use it and give away session keys without >> the knowledge or consent of the client. > > I have no clue what you mean. Then think about the situation in which the proxy has the encryption keys and the authentication keys, and yet there is just a single TLS session, and consider the changes that would be needed to the TLS protocol in order to retain security even when the proxy is modifying the session data. > If the proxy terminates the clients > TLS connection and establishes a new connection to the real server, > then it will have to impersonate the real server to the client No, that's not right, at least not if "impersonate" is meant in the cryptographic sense. If "impersonate" is meant in the sense that a proxy can modify the traffic passing through it, then yes, that is a goal for the system; it is a requirement if TLS is to be used to protect communications when an HTTP proxy is present (for many types of proxies). > in any case > and will always have all keying material available to do anything bad > to either or both peers. > In any solution in which a proxy has session keys, it is required that the client and server trust the proxy to do the right thing. One thing that really surprises me about your line of thinking is the fact that you feel that a protocol that can propagate a session key to a proxy would encourage better respect of privacy. A server could use that protocol to pass keys to a middlebox without the knowledge or consent of the client, and the client could do so without the knowledge or consent of the server. With the key propagation approach, there is very little that you and I can do to prevent this sort of behavior. (Side note: one could design a solution that required both the client and server to approve of the presence of the proxy; in fact, I've been through that design exercise. However, it would be easy for implementers to ignore the stipulation that both sides accede to the proxy, and they would be motivated to do so.) I think we've both stated our views well enough that people have a reasonable idea of what we think. It would be good to let others who care about the topic have a chance to offer their own thoughts. David > So security-wise, the TLS proxy that you are proposing is at the > far end of badness, there is _nothing_ that can possibly be worse, > but a few thinghs might be *MUCH* better. > > > -Martin From mcgrew@cisco.com Mon Aug 1 12:32:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED14A11E8147 for ; Mon, 1 Aug 2011 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.733 X-Spam-Level: X-Spam-Status: No, score=-102.733 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYzJu+nGUeTY for ; Mon, 1 Aug 2011 12:32:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3836211E8144 for ; Mon, 1 Aug 2011 12:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1069; q=dns/txt; s=iport; t=1312227150; x=1313436750; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=8CPVIf/qTux4ovPah8X+0ItXATtWuT+BdHfozMwOTSU=; b=IKlE1QZbytmwJ7WETaukPWVl0Z42mXhmjuUxPmqufSr5fa35Q9AkX802 47UzAqraNswezdn4tu2bNC1zAfwfXxT8J9Hbb+TsWRric3yzYCV5mWNjm UGXWSYuNnlcMnCA8A8T9sekhRVz2rN/9kWdsX77ML92U6x09dXitlJ1Ns M=; X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8547735" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2011 19:32:30 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71JWSx8005377; Mon, 1 Aug 2011 19:32:29 GMT Message-Id: <4CD821BE-2BB9-474A-8720-C86B4120444E@cisco.com> From: David McGrew To: mrex@sap.com In-Reply-To: <201108011650.p71Goc7j021785@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Aug 2011 12:32:28 -0700 References: <201108011650.p71Goc7j021785@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:32:24 -0000 On Aug 1, 2011, at 9:50 AM, Martin Rex wrote: > David McGrew wrote: >> >> That property does not hold for any use of authenticated encryption, >> including that of RFC 5288 or the two drafts using CCM. > > > Which means that security-wise those cipher suites are substantially > weaker than tls cipher suites which provide encryption and integrity > by independent means. calling authenticated encryption "weaker" is wrong. I believe what you mean to say is that it doesn't have this side property that you think is important. Perhaps it is important, but it is not security property. Historically, several real world protocols and systems have weakness due to poor design decisions with respect to combining authentication and encryption, and the use of AEAD prevents that sort of problem. As a side note: AEAD algorithms could be designed that have the property that you want, and in fact Ken Grewal and Men Long proposed exactly such a thing as a variant of GCM; see draft-grewal-aes-gcm- bifurcated-key-00. David From ietfc@btconnect.com Mon Aug 1 13:36:36 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A1B1F0C3F for ; Mon, 1 Aug 2011 13:36:36 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fAQuDB6UcYG for ; Mon, 1 Aug 2011 13:36:36 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id B9A3F1F0C3E for ; Mon, 1 Aug 2011 13:36:35 -0700 (PDT) Received: from host109-153-78-164.range109-153.btcentralplus.com (HELO pc6) ([109.153.78.164]) by c2bthomr09.btconnect.com with SMTP id DXN33127; Mon, 01 Aug 2011 21:36:20 +0100 (BST) Message-ID: <003f01cc5081$d8fa7e40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Peter Gutmann" , References: Date: Mon, 1 Aug 2011 21:30:14 +0200 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 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E370E43.002C, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.8.1.193614:17:9.535, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, ECARD_WORD, __HASHBUSTER_BLOCK_V2_1, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, HASHBUSTER_BLOCK_V2, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E370E55.00BB,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:36:36 -0000 ---- Original Message ----- From: "Peter Gutmann" To: Cc: Sent: Thursday, July 28, 2011 8:11 AM Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers > Martin Rex writes: > >Anders Rundgren wrote: > >> Lots of banks wants to use CCA for their users. > > > >That is a non sequitur. > > > >Banks (here in Germany) have abandoned tradtional TANs based on the > >unconditional presumption that client PCs are infested with malware, and > >most banks in Germany are currently replacing indexed TANs (iTAN) presumably > >based on the perception that malware on clients (trojans/phishing) has caught > >up with iTAN procedure complexity. > > > >At this point, with the presumption that all client PCs are thoroughly > >infested with malware, going for a Single Sign-On mechanism would be > >completely braindead and irresponsible. > > That was my feeling as well. Moving from TANs (or plain passwords if you're a > US bank) to client certs is at best pointless and at worst a step backwards in > security. Even if you could overcome the monumental usability problems (and > there's no evidence that we can do this), you end up with a mechanism that's > even less secure than basic TANs because use of a TAN requires human > intervention while a MITB (man-in-the-browser) can use your private key to > sign whatever they want as often as they want without your knowledge. Client- > side PKI was designed for an attack model invented by cryptographers to > justify the use of fun crypto stuff, but it has little (if anything) to do > with the threats that we're actually facing today. > Coincidentally, one of the five big UK banks has today, 1st August, announced HSBC Secure Key, a hand held card device that turns your PIN into a one-time six digit passcode. No technical details, but the advertisement claims that is is an improvement on the German WWII devices (and half the advertisement is encrypted - HX01896a1 54f30cd38 ...). Another of the banks, Barclays, has had PINsentry for a while, which takes your PIN and your debit card to generate a 8 digit passcode. I have yet to use either but have seen technology similar to the former used extensively in an Enterprise setting, for use by travelling salesmen in hotels etc. Tom Petch > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Mon Aug 1 13:38:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875B81F0C49 for ; Mon, 1 Aug 2011 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.929 X-Spam-Level: X-Spam-Status: No, score=-9.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8wvftTHGghK for ; Mon, 1 Aug 2011 13:38:30 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id AB91B1F0C3D for ; Mon, 1 Aug 2011 13:38:28 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p71KcW1S011117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 22:38:32 +0200 (MEST) From: Martin Rex Message-Id: <201108012038.p71KcVDj004957@fs4113.wdf.sap.corp> To: mcgrew@cisco.com (David McGrew) Date: Mon, 1 Aug 2011 22:38:31 +0200 (MEST) In-Reply-To: <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> from "David McGrew" at Aug 1, 11 12:15:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:38:30 -0000 David McGrew wrote: > > Martin Rex wrote: > > > > You're trying to give the proxy the authority to impersonate > > _every_ server. > > On the contrary, the goal here is to not have the proxy impersonate > any other device, at least not impersonate in the cryptographic sense. Exactly in that sense. You do not have the slightest proof that the server, which your proxy impersonates, is actually involved. The proxy could be making up the entire conversation and the client will not be able to tell the difference. > > I think the right theoretical approach to analyzing this sort of > protocol would be to start with a formal model of TLS as a two-party > authentication protocol, and extend it to accomodate a three-party > system with the appropriate role definitions. Been there, done that, and really disliked it: http://tools.ietf.org/html/draft-housley-evidence-extns-01 > > >> > >> It would make crypto validation considerably harder if not > >> impossible. > > > > Nope. That is orthogonal. > > On the above three points: allowing a proxy to coordinate betwen two > TLS sessions allows one to preserve most of the TLS protocol and > implementation. You mean by having the entire TLS security architecture walk the plank, you could get away with fairly minor code changes? > > It seems like a major difference that we have is that you expect a > "read only" solution to be viable, while I don't. A read-only > decryption proxy would be considerably easier to implement correctly. > However, I have zero confidence that a read-only decryption proxy > would not evolve into a read/write proxy, which would introduce very > significant security problems. Such an evolution would have the prerequisite of a client cooperating. And your solution to not have pretty TLS loose virginity at some point in the future, is to rape her right away, i.e. start with an almighty TLS proxy? -Martin From therbst@silverspringnet.com Mon Aug 1 14:13:15 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602B41F0C3D for ; Mon, 1 Aug 2011 14:13:14 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrGFSgsQGY5m for ; Mon, 1 Aug 2011 14:13:13 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 716851F0C39 for ; Mon, 1 Aug 2011 14:13:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroGAHsWN04KyAE+/2dsb2JhbABCgk2mAgeBNxB5EgELAQlrJgEEDshjhkIEh1qQRotf X-IronPort-AV: E=Sophos;i="4.67,302,1309762800"; d="scan'208,217";a="6324243" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 01 Aug 2011 14:13:19 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Mon, 1 Aug 2011 14:13:18 -0700 From: Thomas Herbst To: "tls@ietf.org" Date: Mon, 1 Aug 2011 14:13:17 -0700 Thread-Topic: working group discussion of draft-mcgrew-tls-aes-ccm-01 Thread-Index: AcxQj9WedFost6MXQxSYaO/B5tiFCw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA5C64FDF40Atherbstsilverspringnetcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 01 Aug 2011 14:15:16 -0700 Cc: Thomas Herbst , "mcgrew@cisco.com" Subject: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:13:15 -0000 --_000_CA5C64FDF40Atherbstsilverspringnetcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure where this fits into the wg chair's extensions triaging, but was h= oping for an update on draft-mcgrew-tls-aes-ccm-01 last week. In Zigbee we'd specified ccm as most of the 802.15.4 chips have hardware su= pport. tom --_000_CA5C64FDF40Atherbstsilverspringnetcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not sure where this fits= into the wg chair's extensions triaging, but was hoping for an update on&n= bsp;draft-mcgrew-tls-aes-ccm-01 last week.

In Zigb= ee we'd specified ccm as most of the 802.15.4 chips have hardware support.<= /div>

tom

--_000_CA5C64FDF40Atherbstsilverspringnetcom_-- From mcgrew@cisco.com Mon Aug 1 17:14:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6CE21F8747 for ; Mon, 1 Aug 2011 17:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.727 X-Spam-Level: X-Spam-Status: No, score=-102.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meUYyD4PuSzI for ; Mon, 1 Aug 2011 17:14:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 263F621F8588 for ; Mon, 1 Aug 2011 17:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2263; q=dns/txt; s=iport; t=1312244062; x=1313453662; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=2s0dwlJj0GZQR7LeK9WO3kh8Bam6DJB5EsoBBfjYJOc=; b=GaAW5FSASa1+q2+oXMTNkGBRcGdsmltRcWRojlM3nAxd4O+sB9INC3T/ gAPY/UwbaPd5QTAoNAn88CMbdX0FD0cVCqqp8/BJm/4e3jQtXds8DLn2c SzNkTcHpzxyyWl2iOGIS2N6JkBXc9VsNEOapuuWwoCPw0EvU1uD1/LvYq U=; X-IronPort-AV: E=Sophos;i="4.67,303,1309737600"; d="scan'208";a="8620478" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2011 00:13:16 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p720DE6c009606; Tue, 2 Aug 2011 00:13:15 GMT Message-Id: <568A2EE4-21EF-4BD4-BF0E-84D918D0FB76@cisco.com> From: David McGrew To: mrex@sap.com In-Reply-To: <201108012038.p71KcVDj004957@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Aug 2011 17:13:14 -0700 References: <201108012038.p71KcVDj004957@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 00:14:34 -0000 On Aug 1, 2011, at 1:38 PM, Martin Rex wrote: > David McGrew wrote: >> >> Martin Rex wrote: >>> >>> You're trying to give the proxy the authority to impersonate >>> _every_ server. >> >> On the contrary, the goal here is to not have the proxy impersonate >> any other device, at least not impersonate in the cryptographic >> sense. > > Exactly in that sense. You do not have the slightest proof that > the server, which your proxy impersonates, is actually involved. > The proxy could be making up the entire conversation and the > client will not be able to tell the difference. > > >> >> I think the right theoretical approach to analyzing this sort of >> protocol would be to start with a formal model of TLS as a two-party >> authentication protocol, and extend it to accomodate a three-party >> system with the appropriate role definitions. > > Been there, done that, and really disliked it: > http://tools.ietf.org/html/draft-housley-evidence-extns-01 > > >> >>>> >>>> It would make crypto validation considerably harder if not >>>> impossible. >>> >>> Nope. That is orthogonal. >> >> On the above three points: allowing a proxy to coordinate betwen two >> TLS sessions allows one to preserve most of the TLS protocol and >> implementation. > > You mean by having the entire TLS security architecture walk the > plank, > you could get away with fairly minor code changes? > > >> >> It seems like a major difference that we have is that you expect a >> "read only" solution to be viable, while I don't. A read-only >> decryption proxy would be considerably easier to implement correctly. >> However, I have zero confidence that a read-only decryption proxy >> would not evolve into a read/write proxy, which would introduce very >> significant security problems. > > Such an evolution would have the prerequisite of a client cooperating. > > And your solution to not have pretty TLS loose virginity at some point > in the future, is to rape her right away, i.e. start with an > almighty TLS proxy? > > > -Martin Those are colorful metaphors. I assume that if you are willing to deploy such rhetorical excess, you do not actually understand what is being proposed. David From pgut001@login01.cs.auckland.ac.nz Mon Aug 1 21:58:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A4E21F8C90 for ; Mon, 1 Aug 2011 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uur3tF9BBXuE for ; Mon, 1 Aug 2011 21:58:16 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3025921F8D78 for ; Mon, 1 Aug 2011 21:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1312261104; x=1343797104; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ietfc@btconnect.com,=20mrex@sap.com,=20pgut001@cs. auckland.ac.nz|Subject:=20Re:=20[TLS]=20HTTPS=20client-ce rtificate-authentication=20in=20browsers|Cc:=20tls@ietf.o rg|In-Reply-To:=20<003f01cc5081$d8fa7e40$4001a8c0@gateway .2wire.net>|Message-Id:=20|Date:=20Tue,=2002=20Aug=202011=2016:58:13 =20+1200; bh=Te8ypRUYCsqqjMzDxlNJHQdDcjoIDC4VaY5NJZuF2XY=; b=dCXd79MqHuDRXmp0njGNyR3kR/UJZjQULKHtrX6sJ/XmFcjjReUYPeTU 5p0D2VPZ5TultLqqXl/suV75NIK93joFZUtZjmwg0tUFIxPpa0jPEdtps ugIntKIBx2PQdy8hl4Q5VHNbF8udv/4ZNN4kEhE3VhTIAKz97SQyNKvdc g=; X-IronPort-AV: E=Sophos;i="4.67,305,1309694400"; d="scan'208";a="75470304" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Aug 2011 16:58:13 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qo73V-0007aC-GN; Tue, 02 Aug 2011 16:58:13 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qo73V-0000Gv-1I; Tue, 02 Aug 2011 16:58:13 +1200 From: Peter Gutmann To: ietfc@btconnect.com, mrex@sap.com, pgut001@cs.auckland.ac.nz In-Reply-To: <003f01cc5081$d8fa7e40$4001a8c0@gateway.2wire.net> Message-Id: Date: Tue, 02 Aug 2011 16:58:13 +1200 Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 04:58:17 -0000 "t.petch" writes: >Coincidentally, one of the five big UK banks has today, 1st August, announced >HSBC Secure Key, a hand held card device that turns your PIN into a one-time >six digit passcode. No technical details, It's just a SecurID variant, so no better than the static TANs that the German banks are abandoning. >Another of the banks, Barclays, has had PINsentry for a while, which takes >your PIN and your debit card to generate a 8 digit passcode. The Barclays device is a Gemalto CAP reader rebranded. I don't know how Barclays are using it (given the security record of UK banks it'll be "incorrectly"), but if used correctly it's actually phishing- resistant, you enter the transaction details and it generates a crypto MAC from them which prevents a MITB attack. Of course as certain folks from Cambridge have pointed out, you then have to implement the underlying protocols correctly in order for the whole thing to be secure, but it's good enough to stop phishers/MITB. Peter. From ynir@checkpoint.com Mon Aug 1 23:19:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5293D11E8088 for ; Mon, 1 Aug 2011 23:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zn9-uX483L5 for ; Mon, 1 Aug 2011 23:19:56 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B6BB011E8075 for ; Mon, 1 Aug 2011 23:19:55 -0700 (PDT) X-CheckPoint: {4E37A498-22-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p726Jwgd029022; Tue, 2 Aug 2011 09:19:58 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 2 Aug 2011 09:19:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 2 Aug 2011 09:19:57 +0300 From: Yoav Nir To: David McGrew Date: Tue, 2 Aug 2011 09:19:58 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxQ3DOXcF4GIooHTQmDOrRid1N2Gw== Message-ID: References: <201108012038.p71KcVDj004957@fs4113.wdf.sap.corp> <568A2EE4-21EF-4BD4-BF0E-84D918D0FB76@cisco.com> In-Reply-To: <568A2EE4-21EF-4BD4-BF0E-84D918D0FB76@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pgladstone@cisco.com" , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 06:19:57 -0000 On Aug 2, 2011, at 3:13 AM, David McGrew wrote: >=20 > On Aug 1, 2011, at 1:38 PM, Martin Rex wrote: >=20 >>> It seems like a major difference that we have is that you expect a >>> "read only" solution to be viable, while I don't. A read-only >>> decryption proxy would be considerably easier to implement correctly. >>> However, I have zero confidence that a read-only decryption proxy >>> would not evolve into a read/write proxy, which would introduce very >>> significant security problems. Decryption-only through sharing of keys would not work. Some of the process= ing to be done cannot be done by a passive eavesdropper. For example, if yo= u send me an MS-Word document to my gmail account, and I would like to down= load it, the way to check for malware is for the proxy to download the enti= re file, scan it for malware, and then forward it to my computer. A passive= eavesdropper would finish collecting the file too late - by then I already= have it. An active proxy is necessary. >>=20 >> Such an evolution would have the prerequisite of a client cooperating. >>=20 >> And your solution to not have pretty TLS loose virginity at some point >> in the future, is to rape her right away, i.e. start with an >> almighty TLS proxy? >>=20 >>=20 >> -Martin >=20 > Those are colorful metaphors. I assume that if you are willing to =20 > deploy such rhetorical excess, you do not actually understand what is =20 > being proposed. I think he's missing the baseline. The baseline is that TLS proxies work we= ll enough that companies deploy then. Even in Europe. There are some downsi= des to using them: client certificates and PSK suites don't work. Certifica= te and CA pinning don't work. The user cannot verify the actual server cert= ificate chain. The EV indication is gone. But all these are not blocking ad= ministrators from deploying TLS proxies. They may be blocking sites from us= ing client certificates or PSK suites, although there are plenty of other t= hings blocking those (but that's from another thread) This extension may help with those deficiencies. With or without the extens= ion, the existence (or possibility) of the proxy is visible to the user, be= cause you need to install a CA certificate. A user can choose not to use th= e corporate network for accessing HTTPS sites where he's not comfortable wi= th having the content inspected. The fact that the server is not similarly = given a choice may be a problem, but that is a property of using TLS withou= t client authentication. The extension can help, but only if the proxy uses= it. Yoav From anders.rundgren@telia.com Tue Aug 2 02:51:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3349221F8EB8 for ; Tue, 2 Aug 2011 02:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7a5mlOh5Vkh for ; Tue, 2 Aug 2011 02:51:03 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id F326921F8EB6 for ; Tue, 2 Aug 2011 02:51:02 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E970017339B for tls@ietf.org; Tue, 2 Aug 2011 11:51:10 +0200 Message-ID: <4E37C88A.9030402@telia.com> Date: Tue, 02 Aug 2011 11:51:06 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: tls@ietf.org References: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> In-Reply-To: <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 09:51:05 -0000 The discussion in a nutshell: http://www.dilbert.com/fast/2011-08-02 On 2011-08-01 21:15, David McGrew wrote: > > On Aug 1, 2011, at 9:15 AM, Martin Rex wrote: > >> David McGrew wrote: >>> >>> Again, it seems that you do not quite understand what we are trying >>> to >>> achieve. There is current practice that uses proxies in a way that >>> is bad for clients (and you outline many of the reasons below). We >>> aim to improve the situation for clients and the security of the >>> overall solution. One important point: it is possible to design a >>> solution in which the proxy does not contain a CA. >> >> You're trying to give the proxy the authority to impersonate >> _every_ server. > > On the contrary, the goal here is to not have the proxy impersonate > any other device, at least not impersonate in the cryptographic sense. > >> Whether it is through an super-CA-cert or whether >> you're extending the protocol so that the client believes a forwarded >> certificate with _no_ proof-of-posession for that cert is a mere >> implementation detail, and has no impact of the size of the security >> problem that you want to newly create. >> > > It's hard to parse that sentence, but if I understand you right, you > think that it is important for the client to have a strong assurance > that the subject of the server certificate is an active participant in > the session. I agree that is a highly desirable property. > > I think the right theoretical approach to analyzing this sort of > protocol would be to start with a formal model of TLS as a two-party > authentication protocol, and extend it to accomodate a three-party > system with the appropriate role definitions. Fortunately, only the > authentication aspects need to be considered, and some of the key > establishment goals can be ignored, which makes the analysis easier. > If we had the freedom to design the system from scratch, the obvious > approach would be to have C, S, and P each issue nonces that get > signed by each other party, along with the other data that gets > currently signed, and indication of the role of each signer. What is > most interesting is: how close can one get to this ideal protocol by > extending TLS? > >> >>> >>> Propagating TLS session key material is a worse idea for a lot of >>> reasons. It would be a fragile solution in which easy-to-make >>> implementation mistakes could undermine security. >> >> I'm sorry, but that is a completely bogus claim. >> >> If the proxy is terminating both TLS connections, it will have access >> to traffic encryption and mac keys of both connections can can leak >> those just as easily. Sharing the traffic encryption keys will not >> make this any worse. >> >> >>> >>> It would require considerable new implementation work. >> >> You mean because it would require an additional network channel to >> talk to the proxy? yes. It can not happen "by accident". >> >> >>> >>> It would make crypto validation considerably harder if not >>> impossible. >> >> Nope. That is orthogonal. > > On the above three points: allowing a proxy to coordinate betwen two > TLS sessions allows one to preserve most of the TLS protocol and > implementation. In contrast, a solution that propagates session keys > will require new implementation work for the data plane, state > management, and so on. If the proxy attempts to modify the session, > all sorts of significant crypto problems will crop up. There will be > HTTP proxies that expect to modify the traffic, and it would be unwise > to expect that a proxy implementer would respect the injunction to not > modify the session, if a specification for session key propagation > were developed. > > It seems like a major difference that we have is that you expect a > "read only" solution to be viable, while I don't. A read-only > decryption proxy would be considerably easier to implement correctly. > However, I have zero confidence that a read-only decryption proxy > would not evolve into a read/write proxy, which would introduce very > significant security problems. > >> >> >>> >>> If it aimed to preserve end-to-end authentication, it would be >>> fundamentally incompatible with Authenticated Encryption in general >>> and the AEAD facility in TSL 1.2 in particular, and it would probably >>> end up getting misused and abused in practice. >> >> Correct, the use of AEAD would break the security, since this mode >> does >> not use seperate traffic encryption and mac keys. Personally, I >> consider >> AEAD a bad idea, so I don't mind disabling these cipher suites when >> traversing such a proxy. >> > > Your personal opinion on AEAD goes against a lot of theory and > standards work of the last decade. Have you considered providing your > criticisms in writing? > >> >>> >>> If it did not aim to preserve end-to-end authentication, >>> then it would require considerable changes to the TLS protocol, to >>> prevent keystream insertion attacks and keystream re-use. Perhaps >>> worst of all, it would create a mechanism that could more easily be >>> abused; a server could (mis)use it and give away session keys without >>> the knowledge or consent of the client. >> >> I have no clue what you mean. > > Then think about the situation in which the proxy has the encryption > keys and the authentication keys, and yet there is just a single TLS > session, and consider the changes that would be needed to the TLS > protocol in order to retain security even when the proxy is modifying > the session data. > > >> If the proxy terminates the clients >> TLS connection and establishes a new connection to the real server, >> then it will have to impersonate the real server to the client > > No, that's not right, at least not if "impersonate" is meant in the > cryptographic sense. If "impersonate" is meant in the sense that a > proxy can modify the traffic passing through it, then yes, that is a > goal for the system; it is a requirement if TLS is to be used to > protect communications when an HTTP proxy is present (for many types > of proxies). > > >> in any case >> and will always have all keying material available to do anything bad >> to either or both peers. >> > > In any solution in which a proxy has session keys, it is required that > the client and server trust the proxy to do the right thing. > > One thing that really surprises me about your line of thinking is the > fact that you feel that a protocol that can propagate a session key to > a proxy would encourage better respect of privacy. A server could use > that protocol to pass keys to a middlebox without the knowledge or > consent of the client, and the client could do so without the > knowledge or consent of the server. With the key propagation > approach, there is very little that you and I can do to prevent this > sort of behavior. (Side note: one could design a solution that > required both the client and server to approve of the presence of the > proxy; in fact, I've been through that design exercise. However, it > would be easy for implementers to ignore the stipulation that both > sides accede to the proxy, and they would be motivated to do so.) > > I think we've both stated our views well enough that people have a > reasonable idea of what we think. It would be good to let others who > care about the topic have a chance to offer their own thoughts. > > David > >> So security-wise, the TLS proxy that you are proposing is at the >> far end of badness, there is _nothing_ that can possibly be worse, >> but a few thinghs might be *MUCH* better. >> >> >> -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ynir@checkpoint.com Tue Aug 2 05:18:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8173321F8B3D for ; Tue, 2 Aug 2011 05:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWZ8Wlgo9Tus for ; Tue, 2 Aug 2011 05:18:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5C27921F8E17 for ; Tue, 2 Aug 2011 05:18:37 -0700 (PDT) X-CheckPoint: {4E37F892-E-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p72CIArL007667; Tue, 2 Aug 2011 15:18:10 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 2 Aug 2011 15:18:10 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 2 Aug 2011 15:18:10 +0300 From: Yoav Nir To: Marsh Ray Date: Tue, 2 Aug 2011 15:18:11 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxRDj2jP8BNBdf7RCKEzB6nCRFniA== Message-ID: In-Reply-To: <4E36C607.4040504@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Philip Gladstone , David McGrew , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 12:18:50 -0000 On 8/1/11 6:28 PM, "Marsh Ray" wrote: >On 08/01/2011 10:08 AM, Yoav Nir wrote: >> >> I'm also thinking about whether we can get client certificates to work. >> The hard problem is that Certificate Verify signs the handshake >>messages, >> and those are not available to the client. I don't think we want to send >> all the previous handshake messages in the extension, so getting this to >> work would also require a server-side change. > >You could just send the MD5/SHA-1/SHA-256 hashes of the messages, which >is what the client cert signs. Alternatively, we could have the client sign its own ClientHello, and send that in the Certificate Verify payload. The proxy would send the client's ClientHello in the extension, and forward the client's CertificateVerify. Then we don't have the escalation of privilege. From thewirelessmacdude@yahoo.com Tue Aug 2 05:50:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B234121F8DA5 for ; Tue, 2 Aug 2011 05:50:57 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFMLnrG9bNAh for ; Tue, 2 Aug 2011 05:50:56 -0700 (PDT) Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id C445121F8DA7 for ; Tue, 2 Aug 2011 05:50:56 -0700 (PDT) Received: from [98.139.91.69] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 02 Aug 2011 12:51:01 -0000 Received: from [98.139.91.5] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 02 Aug 2011 12:51:01 -0000 Received: from [127.0.0.1] by omp1005.mail.sp2.yahoo.com with NNFMP; 02 Aug 2011 12:51:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 989942.10330.bm@omp1005.mail.sp2.yahoo.com Received: (qmail 31170 invoked by uid 60001); 2 Aug 2011 12:51:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312289460; bh=K9kR5TP+6+h41TYF6rzLG165sCUTK1Xb6VLCbdOkvIc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=VXaA1bZLEvPZkzhqtHgbfrUGkygPk1u18tlPYrxrRomCMbEixgtj/pf1abARESbVJ0iVwD3IEzcpRy2+K4R2Zy9UCsyto64XtgL+LApt9Ad6AIeOIuR/ONY5HIZAk2Qhiko+dJ36bOMbSoFUXevCng/Z0GvrpgKHM9kfodDpXO0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LR8Y9kzKVnUbeCfGmvsm5tn+KVIpZSWmxH+xoA7NY0xO0/zrTilUQ5w3mK9aDo7dcGiVNt8pZamZA19ABaWeXwazuYt7JVCemOaIZVhCba42W3uVvzFNgI7a+c4jYSwS/VrNd0ZhL+ACR7fSJ4rhgKlPTnz0+vZqiNwPhtchOGw=; X-YMail-OSG: eiux6TYVM1lcoxIOAbYVnlHy2xajl3LrGpADLqD1wYkIYnh Rrd16o5Dkl8oTjcLAaG.6.XIrSYoQhncvpn6fD00Hzdh3rY75XKrHqmXsyj. TocVaNCe.5_75AB7x5Odl1PXAQmsV_y.o1De5wm1OM5_3rCXZ_tcjmUAjyd. o4ptHhZOIahKk5Y4R4Lo_5zVSljM5Yo9rzQ5b6AFzBMoSfj1dZnBBKgpo437 A0KK1A93bQSWCV6MAUHbNZABqCHsQXFABHiT1A_9Pgc59LPpsqUBKmADRxnF ZOBRT4RI2IWvtCV76K8pStJoxj2Mct3YMYb9VbhSpQj0bN05vNLi5VOJ58Co ljzgUIEXDVOOh64rOODHYrhxQjKJ0liYM9r0YnzWNfb5EQx2siIuHDUvSOhE 7MaWYQGISkmewBzLfD7ty8eZNqCi6DRvQYYamKEw4y7jy9L5j_WYgLxbMQQ- - Received: from [198.208.159.18] by web111723.mail.gq1.yahoo.com via HTTP; Tue, 02 Aug 2011 05:51:00 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.113.313619 Message-ID: <1312289460.11772.YahooMailClassic@web111723.mail.gq1.yahoo.com> Date: Tue, 2 Aug 2011 05:51:00 -0700 (PDT) From: Ken Peirce To: tls@ietf.org In-Reply-To: <4E37C88A.9030402@telia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 12:50:57 -0000 After watching the back and forth on TLS proxies, and the ever increasing complexity of proposed bandaids to cover individual vulnerabilities, this is starting to look like rearranging the deck chairs on the Titanic. TLS is used by people to insure end to end integrity and privacy, usually, with PKI. Users are protected from intermediate parties if the system architects and TLS management by the controlling application have correctly handled the design of the PKI(e.g. insuring that the CN is in fact the desired name and that the root certificate applicable to the presented certificate are as expected, etc.). If you want to proxy, you are delegating trust to another entity and effectively running a tandem pair of TLS sessions. IMHO, this is not a protocol issue. It is a systems engineering exercise in trust relationships. Most security people I know would agree with me that complexity is the enemy of security. Adding all of these modifications to the protocol only increases the chances of introducing new holes in its protection. Ken Peirce > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From pgut001@login01.cs.auckland.ac.nz Tue Aug 2 06:11:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDDE21F8ACC for ; Tue, 2 Aug 2011 06:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw8ok0A6a3xJ for ; Tue, 2 Aug 2011 06:11:50 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id CF6A421F8AB8 for ; Tue, 2 Aug 2011 06:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1312290719; x=1343826719; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20thewirelessmacdude@yahoo.com,=20tls@ietf.org |Subject:=20Re:=20[TLS]=20TLS=20Proxy=20Server=20Extensio n|In-Reply-To:=20<1312289460.11772.YahooMailClassic@web11 1723.mail.gq1.yahoo.com>|Message-Id:=20|Date:=20Wed,=2003=20Aug=2020 11=2001:11:49=20+1200; bh=WzrHUrOobo6JLn4j7lhP5I72TiYEt5sas+V9y/YPvXI=; b=NJOPH8m5IlEghnHXMJt65KRFeOR+gdlw0KN8ZpAcx6+kpXv/r7yuDYD+ WDuOR9J7obRwOij0vi4GdMqJdquAGDc6WGsHyv9Ln6C2yywv+de2yXhZp jgjp9hs3asHcbN4LaJ0eInEvRI02PEbSDiB5s6snsU2MkAXdYSFSyeBhr 8=; X-IronPort-AV: E=Sophos;i="4.67,306,1309694400"; d="scan'208";a="75521029" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Aug 2011 01:11:49 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QoElB-0005QU-I9; Wed, 03 Aug 2011 01:11:49 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QoElB-0002Uz-It; Wed, 03 Aug 2011 01:11:49 +1200 From: Peter Gutmann To: thewirelessmacdude@yahoo.com, tls@ietf.org In-Reply-To: <1312289460.11772.YahooMailClassic@web111723.mail.gq1.yahoo.com> Message-Id: Date: Wed, 03 Aug 2011 01:11:49 +1200 Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 13:11:51 -0000 Ken Peirce writes: >TLS is used by people to insure end to end integrity and privacy, usually, >with PKI. Users are protected from intermediate parties if the system >architects and TLS management by the controlling application have correctly >handled the design of the PKI Exactly. The whole point of TLS is to provide a secured tunnel from source to destination, which includes defence against MITMs. If someone wants to do a MITM, violating a principal design feature of the protocol, then that's their problem, and not TLS's. >IMHO, this is not a protocol issue. It is a systems engineering exercise in >trust relationships. Exactly. The response to this is "don't do that, then", not "we'll completely break our protocol to make it do the crazy stuff you want". (If people really want to deploy MITM boxes, put a wildcard cert on the MITM. That's how cellphone gateways have been doing it for years). Peter. From matt@mattmccutchen.net Tue Aug 2 09:31:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2453F21F8559 for ; Tue, 2 Aug 2011 09:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8DrKl5Rwoc9 for ; Tue, 2 Aug 2011 09:31:16 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 68B2221F854C for ; Tue, 2 Aug 2011 09:31:09 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 1B34C280076; Tue, 2 Aug 2011 09:31:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=mcXlWQXsAIM5sRdFwUiWAJ3SyUSNFq+3NDbyXuZwVJT zAhdDnCi7iyZvKwe+ftcVmVPHpSppLg2RRukSWcWR0GWdet2dg6qwibueV0Fez5n wxDUhk/xUXzFEThvrBWAG9avHp7seLq8McO2skuiDrzpSi/lqMeqIJuKHaojIwXQ = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=WozRcOc1GAs0YipTlukBezhWoXQ=; b=rYkIMym8Xf Si7gHZHWWtenf3Agao6ub81HHsbKujHGw4gg+Ylv6MZ4nIVllkvmq6zH1nAdd6ch 1w+Sm9fTY23v3kdibrVRvJkpXiXqeA2osaS395IRL5fIS9qFcWjcIygk8qiWTUzO hjasRsBcjozAxBHE24pMrBVmWMz+93tgc= Received: from [10.5.0.146] (unknown [192.80.55.242]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 7D71828006F; Tue, 2 Aug 2011 09:31:17 -0700 (PDT) From: Matt McCutchen To: Yoav Nir In-Reply-To: References: <201108012038.p71KcVDj004957@fs4113.wdf.sap.corp> <568A2EE4-21EF-4BD4-BF0E-84D918D0FB76@cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 02 Aug 2011 12:31:16 -0400 Message-ID: <1312302676.2174.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 16:31:17 -0000 On Tue, 2011-08-02 at 09:19 +0300, Yoav Nir wrote: > Decryption-only through sharing of keys would not work. Some of the > processing to be done cannot be done by a passive eavesdropper. For > example, if you send me an MS-Word document to my gmail account, and I > would like to download it, the way to check for malware is for the > proxy to download the entire file, scan it for malware, and then > forward it to my computer. A passive eavesdropper would finish > collecting the file too late - by then I already have it. An active > proxy is necessary. You are confusing layers. TLS relies on the flow control of the underlying stream. The proxy would have to split the TCP connection in order to collect the entire file, but it would ultimately send the collected TLS records on to the client verbatim, so the TLS-level behavior would be passive. > I think he's missing the baseline. The baseline is that TLS proxies > work well enough that companies deploy then. Even in Europe. There are > some downsides to using them: client certificates and PSK suites don't > work. Certificate and CA pinning don't work. The user cannot verify > the actual server certificate chain. The EV indication is gone. But > all these are not blocking administrators from deploying TLS proxies. > They may be blocking sites from using client certificates or PSK > suites, although there are plenty of other things blocking those (but > that's from another thread) > > This extension may help with those deficiencies. With or without the > extension, the existence (or possibility) of the proxy is visible to > the user, because you need to install a CA certificate. A user can > choose not to use the corporate network for accessing HTTPS sites > where he's not comfortable with having the content inspected. The fact > that the server is not similarly given a choice may be a problem, but > that is a property of using TLS without client authentication. The > extension can help, but only if the proxy uses it. All agreed. A person using a corporate laptop has no expectation of privacy from the company. The proxy extension just offers a technically more capable solution for that scenario. No one is proposing, per se, that TLS interception be used in any more places than it is now. Of course, interception may now be used in places where it was always desired but could not be used before due to protocol issues. However, it's hard to believe that the proxy extension would change the market and/or legal forces that currently restrain ISPs from routinely intercepting customer traffic, if that is what Martin is worried about. The TLS WG may have a personal distaste for the use case addressed by the extension. But I would reason that the use case is valid, thus the extension is worthy of standardization to get interoperable implementations, and the TLS WG is the best venue available for technical discussion. As David explained (https://www.ietf.org/mail-archive/web/tls/current/msg07920.html), the use case does not constitute wiretapping as defined in RFC 2804. -- Matt From mrex@sap.com Tue Aug 2 10:30:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A9611E80B6 for ; Tue, 2 Aug 2011 10:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.936 X-Spam-Level: X-Spam-Status: No, score=-9.936 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeqzMDEVIg7I for ; Tue, 2 Aug 2011 10:30:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9866111E80B3 for ; Tue, 2 Aug 2011 10:30:43 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p72HUYbS011451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 19:30:39 +0200 (MEST) From: Martin Rex Message-Id: <201108021730.p72HUYem015518@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Tue, 2 Aug 2011 19:30:33 +0200 (MEST) In-Reply-To: <1312302676.2174.31.camel@localhost> from "Matt McCutchen" at Aug 2, 11 12:31:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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, 02 Aug 2011 17:30:44 -0000 Matt McCutchen wrote: > > A person using a corporate laptop has no expectation of privacy from the > company. The proxy extension just offers a technically more capable > solution for that scenario. Not everyone is living in totalitarian countries where this might apply. As I previously said, our constitution provides fundamental gurantees of privacy, and protects against both, government agencies spying on citizens as well as employers spying on employees. > > No one is proposing, per se, that TLS interception be used in any more > places than it is now. Of course, interception may now be used in > places where it was always desired but could not be used before due to > protocol issues. However, it's hard to believe that the proxy extension > would change the market and/or legal forces that currently restrain ISPs > from routinely intercepting customer traffic, if that is what Martin is > worried about. No, it is primarily about the employer spying on employee case, which has been clearly ruled unconstitutional in Germany. But the stiff penal code that might provide sufficient deterrant for ISPs does not universally apply to employers, leaving you with civil action an "cease and desist" and a number of completely clueless entry courts. > > The TLS WG may have a personal distaste for the use case addressed by > the extension. But I would reason that the use case is valid, thus the > extension is worthy of standardization to get interoperable > implementations, and the TLS WG is the best venue available for > technical discussion. As David explained > (https://www.ietf.org/mail-archive/web/tls/current/msg07920.html), the > use case does not constitute wiretapping as defined in RFC 2804. I haven't heard any use cases for the TLS proxy in this discussion that are not factually equivalent to wiretapping. -Martin From mrex@sap.com Tue Aug 2 13:10:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6D21F8634 for ; Tue, 2 Aug 2011 13:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.943 X-Spam-Level: X-Spam-Status: No, score=-9.943 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbkgZPI19N0L for ; Tue, 2 Aug 2011 13:10:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9025021F85FF for ; Tue, 2 Aug 2011 13:10:19 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p72KA7Lu015110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 22:10:07 +0200 (MEST) From: Martin Rex Message-Id: <201108022010.p72KA7AI024538@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 2 Aug 2011 22:10:07 +0200 (MEST) In-Reply-To: <4E31D7C1.7010308@gnutls.org> from "Nikos Mavrogiannopoulos" at Jul 28, 11 11:42:25 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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, 02 Aug 2011 20:10:20 -0000 Nikos Mavrogiannopoulos wrote: > > The other goal of yours of sending raw public keys might as > well be solved by defining a new certificate type RAW in the > certificateType registry defined in RFC6091 and send anything you like > in the "Certificate" message. You don't need WG consensus to do that. > But do you really have a use case that makes all that effort > worthwhile? Why would others be interested into implementing > the RAW keys you are proposing? I find the idea of extending rfc6091 with a new certificate type for raw keys more appealing that a completely new TLS extension. I also prefer the server key to part of the full TLS handshake, so that the situation "client doesn't trust server key" or "client expected different server key" can be reliably distinguished from other reasons of a Finished message verification failure. -Martin From joshua.davies.tx@gmail.com Tue Aug 2 15:27:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2811E80CE for ; Tue, 2 Aug 2011 15:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EmitYZpGuTS for ; Tue, 2 Aug 2011 15:27:02 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id BF72111E80A1 for ; Tue, 2 Aug 2011 15:27:02 -0700 (PDT) Received: by pzk6 with SMTP id 6so344422pzk.26 for ; Tue, 02 Aug 2011 15:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t447ynUFbsf2xzU2P6HdcbyQXbD4dPXRIiDuHJHe7S4=; b=ILpESJ++TkrzOzih1+RYU5YqNbITn/s5B07bdDY8to4DkvmNYvmXyAbWEY+JXWyX/3 Ctfq3l75MK+/F/6GDB6pTi4E0S8ZqB+T6sjAY0d5nFiPSsun6n60rnIAQ2GX0MOjpT7G eOVMt8G7pcYZoxNXel3Vi/xeB9/aGDxsJ9sDQ= MIME-Version: 1.0 Received: by 10.68.28.234 with SMTP id e10mr36070pbh.71.1312324031468; Tue, 02 Aug 2011 15:27:11 -0700 (PDT) Received: by 10.142.230.9 with HTTP; Tue, 2 Aug 2011 15:27:11 -0700 (PDT) In-Reply-To: <201108021730.p72HUYem015518@fs4113.wdf.sap.corp> References: <1312302676.2174.31.camel@localhost> <201108021730.p72HUYem015518@fs4113.wdf.sap.corp> Date: Tue, 2 Aug 2011 17:27:11 -0500 Message-ID: From: Joshua Davies To: mrex@sap.com Content-Type: multipart/alternative; boundary=bcaec520eb1fb9d3d604a98d3fbd Cc: tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 02 Aug 2011 22:27:03 -0000 --bcaec520eb1fb9d3d604a98d3fbd Content-Type: text/plain; charset=ISO-8859-1 > I haven't heard any use cases for the TLS proxy in this discussion > that are not factually equivalent to wiretapping. Hm - it may be factually equivalent to wiretapping, but I can think of a perfectly legitimate use case for a TLS proxy which MITM's a client, with that client's express consent and knowledge of course - wire-level debugging of an encrypted session. I've set something like this up a couple of times to debug a server that doesn't accept plaintext connections but is still not behaving correctly; I create a proxy that presents a self-signed certificate to the client, ignore the security pop-up warning, and then proxy again to the server (logging everything in between). In this case, I'm "wiretapping", but I'm wiretapping myself. On Tue, Aug 2, 2011 at 12:30 PM, Martin Rex wrote: > Matt McCutchen wrote: > > > > A person using a corporate laptop has no expectation of privacy from the > > company. The proxy extension just offers a technically more capable > > solution for that scenario. > > Not everyone is living in totalitarian countries where this might apply. > > As I previously said, our constitution provides fundamental gurantees > of privacy, and protects against both, government agencies spying > on citizens as well as employers spying on employees. > > > > > > No one is proposing, per se, that TLS interception be used in any more > > places than it is now. Of course, interception may now be used in > > places where it was always desired but could not be used before due to > > protocol issues. However, it's hard to believe that the proxy extension > > would change the market and/or legal forces that currently restrain ISPs > > from routinely intercepting customer traffic, if that is what Martin is > > worried about. > > No, it is primarily about the employer spying on employee case, which > has been clearly ruled unconstitutional in Germany. But the stiff penal > code that might provide sufficient deterrant for ISPs does not universally > apply to employers, leaving you with civil action an "cease and desist" > and a number of completely clueless entry courts. > > > > > > The TLS WG may have a personal distaste for the use case addressed by > > the extension. But I would reason that the use case is valid, thus the > > extension is worthy of standardization to get interoperable > > implementations, and the TLS WG is the best venue available for > > technical discussion. As David explained > > (https://www.ietf.org/mail-archive/web/tls/current/msg07920.html), the > > use case does not constitute wiretapping as defined in RFC 2804. > > I haven't heard any use cases for the TLS proxy in this discussion > that are not factually equivalent to wiretapping. > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --bcaec520eb1fb9d3d604a98d3fbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I haven't heard any use cases for the TLS = proxy in this discussion
> that are not factually equivalent to wiret= apping.

Hm - it may be factually equivalent to wiretappi= ng, but I can think of a perfectly legitimate use case for a TLS proxy whic= h MITM's a client, with that client's express consent and knowledge= of course - wire-level debugging of an encrypted session. =A0I've set = something like this up a couple of times to debug a server that doesn't= accept plaintext connections but is still not behaving correctly; I create= a proxy that presents a self-signed certificate to the client, ignore the = security pop-up warning, and then proxy again to the server (logging everyt= hing in between). =A0In this case, I'm "wiretapping", but I&#= 39;m wiretapping myself.

On Tue, Aug 2, 2011 at 12:30 PM, Martin= Rex <mrex@sap.com= > wrote:
Matt McCutchen wrote:
>
> A person using a corporate laptop has no expectation of privacy from t= he
> company. =A0The proxy extension just offers a technically more capable=
> solution for that scenario.

Not everyone is living in totalitarian countries where this might app= ly.

As I previously said, our constitution provides fundamental gurantees
of privacy, and protects against both, government agencies spying
on citizens as well as employers spying on employees.


>
> No one is proposing, per se, that TLS interception be used in any more=
> places than it is now. =A0Of course, interception may now be used in > places where it was always desired but could not be used before due to=
> protocol issues. =A0However, it's hard to believe that the proxy e= xtension
> would change the market and/or legal forces that currently restrain IS= Ps
> from routinely intercepting customer traffic, if that is what Martin i= s
> worried about.

No, it is primarily about the employer spying on employee case, which=
has been clearly ruled unconstitutional in Germany. =A0But the stiff penal<= br> code that might provide sufficient deterrant for ISPs does not universally<= br> apply to employers, leaving you with civil action an "cease and desist= "
and a number of completely clueless entry courts.


>
> The TLS WG may have a personal distaste for the use case addressed by<= br> > the extension. =A0But I would reason that the use case is valid, thus = the
> extension is worthy of standardization to get interoperable
> implementations, and the TLS WG is the best venue available for
> technical discussion. =A0As David explained
> (https://www.ietf.org/mail-archive/web/tls/current/= msg07920.html), the
> use case does not constitute wiretapping as defined in RFC 2804.

I haven't heard any use cases for the TLS proxy in this discussio= n
that are not factually equivalent to wiretapping.


-Martin
__________________________________= _____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--bcaec520eb1fb9d3d604a98d3fbd-- From paul@xelerance.com Tue Aug 2 20:59:38 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3398811E812D for ; Tue, 2 Aug 2011 20:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxzZBf1PP7Xl for ; Tue, 2 Aug 2011 20:59:37 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4232811E8125 for ; Tue, 2 Aug 2011 20:59:37 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id CFA9D571A0; Wed, 3 Aug 2011 00:01:02 -0400 (EDT) Date: Wed, 3 Aug 2011 00:01:02 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <201108022010.p72KA7AI024538@fs4113.wdf.sap.corp> Message-ID: References: <201108022010.p72KA7AI024538@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 03:59:38 -0000 On Tue, 2 Aug 2011, Martin Rex wrote: > I find the idea of extending rfc6091 with a new certificate type > for raw keys more appealing that a completely new TLS extension. The TLS client still needs a way to convey this to the server, so that there is a migration path from full CA bundle to public key. That is, the client needs to be able to ask for "public key only" certificate type. So I believe we would still need a new TLS extension, but not a new TLS message type. > I also prefer the server key to part of the full TLS handshake, so that > the situation "client doesn't trust server key" or "client expected > different server key" can be reliably distinguished from other reasons > of a Finished message verification failure. I see no problems with that. Paul From yaronf.ietf@gmail.com Tue Aug 2 23:11:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE56E21F888A for ; Tue, 2 Aug 2011 23:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCRfPLavqKtL for ; Tue, 2 Aug 2011 23:11:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 335A821F8888 for ; Tue, 2 Aug 2011 23:11:33 -0700 (PDT) Received: by wyj26 with SMTP id 26so348435wyj.31 for ; Tue, 02 Aug 2011 23:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GFAJu8UeSVLHPhuhsvIl1EP07cgijlh93tHNS82zMJw=; b=hZIC+JNAhLOXtq3Scdx2Fvz7kubBZdi0Mot0Dkdg09jy//3sWbLM+J/u/GnOGLM08P j5oDbFiRcBdp32bxv258VjtIc3FrmIiej6jpG645iDlrNRyxGRkZ9h7nfFNyg+tDtOUD qzy2mvbQYsnVE/STJqJQLmFK6l6cpGvYY6Kfc= Received: by 10.227.128.81 with SMTP id j17mr8027038wbs.55.1312351904467; Tue, 02 Aug 2011 23:11:44 -0700 (PDT) Received: from [10.0.0.5] ([109.67.32.186]) by mx.google.com with ESMTPS id fr7sm392654wbb.56.2011.08.02.23.11.43 (version=SSLv3 cipher=OTHER); Tue, 02 Aug 2011 23:11:43 -0700 (PDT) Message-ID: <4E38E69D.3000608@gmail.com> Date: Wed, 03 Aug 2011 09:11:41 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Read-only vs. read-write proxies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 06:11:35 -0000

First, I strongly dislike this type of corporate proxies, and would take the German constitutional regime any time. But in other free countries, this scenario is perfectly OK (legal and socially acceptable), and we need to cater for this use case.

If we break the TLS architecture as proposed here, we will have killed forever any chance of having TLS-level mutual authentication (TLS-PSK, TLS-SRP). This is IMHO too high a price for the benefits of R/W proxies.

I have not been convinced by David's explanation of the need for R/W proxies, nor by Yoav's use case. A malware detection proxy can drop the connection precisely at the time malware is detected: the Word document would not be received in its entirety and would be rejected by the client. Even if a partial document is acceptable (e.g. JPEG), a partial malware is (hopefully) not effective.

What are the reasons proxies need to modify the stream?

- Purely informational app-level insertion, of the "sent from my iPhone" kind. The *client* has a trusted channel to the proxy, and if this is needed, the client can insert this stuff.

- Security-specific signaling, of the "no spam detected here" kind. The server wouldn't trust the proxy with that anyway (this is a client-side proxy!) so this is not useful.

- Malware detection: just ax the connection.

- Other reasons?

Lastly, it is important that the server should know of the proxy's presence, even if the indication relies on the client's and/or the proxy's good will. I can think of banks who still use passwords for client auth, but would not allow logins where that password is clearly intercepted by a third party.

Thanks,

    Yaron

From n.mavrogiannopoulos@gmail.com Tue Aug 2 23:12:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9358D21F889F for ; Tue, 2 Aug 2011 23:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibCnj3pPas2F for ; Tue, 2 Aug 2011 23:12:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C97B021F889D for ; Tue, 2 Aug 2011 23:12:12 -0700 (PDT) Received: by wyj26 with SMTP id 26so348752wyj.31 for ; Tue, 02 Aug 2011 23:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=og0SjYrMG+ay1kUpTlRSEQaAhgll3oTPJoeqPD3fAU4=; b=AVp55Ii9iFmQ0nRLNwWkgEyfMHA5K5VR8rKOTVfpHtKEe8EIBeNTgVIkCSJyFInKw5 6zJS1AzdVq2SkVFQQzGENvx7mwoAHoZjZq5+83Xo7aepbi93kmqWrie34UokTnkrkWCP UpFkM+GtPFWP8XuOs/kruzB5LjOiENAi2G8qQ= Received: by 10.216.135.71 with SMTP id t49mr2547745wei.43.1312351943245; Tue, 02 Aug 2011 23:12:23 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id n33sm299402weq.36.2011.08.02.23.12.20 (version=SSLv3 cipher=OTHER); Tue, 02 Aug 2011 23:12:21 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E38E6C3.2030405@gnutls.org> Date: Wed, 03 Aug 2011 08:12:19 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Paul Wouters References: <201108022010.p72KA7AI024538@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 06:12:13 -0000 On 08/03/2011 06:01 AM, Paul Wouters wrote: > On Tue, 2 Aug 2011, Martin Rex wrote: > >> I find the idea of extending rfc6091 with a new certificate type >> for raw keys more appealing that a completely new TLS extension. > The TLS client still needs a way to convey this to the server, so that > there is a migration path from full CA bundle to public key. That is, > the client needs to be able to ask for "public key only" certificate type. > So I believe we would still need a new TLS extension, but not a new TLS > message type. And doesn't RFC6091 define the extension? From ynir@checkpoint.com Tue Aug 2 23:24:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8286C11E80C9 for ; Tue, 2 Aug 2011 23:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1Pv4It6QuT9 for ; Tue, 2 Aug 2011 23:24:09 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 88CCE11E8070 for ; Tue, 2 Aug 2011 23:24:08 -0700 (PDT) X-CheckPoint: {4E38F706-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p736O0NI014895; Wed, 3 Aug 2011 09:24:00 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 3 Aug 2011 09:23:59 +0300 From: Yoav Nir To: Joshua Davies Date: Wed, 3 Aug 2011 09:23:57 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxRpe2jDEp0wl1qQimD/3RWBjkQMw== Message-ID: <8D82125F-4C05-4E4D-9C53-9AD4CE4E14AD@checkpoint.com> References: <1312302676.2174.31.camel@localhost> <201108021730.p72HUYem015518@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 06:24:09 -0000 On Aug 3, 2011, at 1:27 AM, Joshua Davies wrote: > > I haven't heard any use cases for the TLS proxy in this discussion > > that are not factually equivalent to wiretapping. >=20 > Hm - it may be factually equivalent to wiretapping, but I can think of a = perfectly legitimate use case for a TLS proxy which MITM's a client, with t= hat client's express consent and knowledge of course - wire-level debugging= of an encrypted session. I've set something like this up a couple of time= s to debug a server that doesn't accept plaintext connections but is still = not behaving correctly; I create a proxy that presents a self-signed certif= icate to the client, ignore the security pop-up warning, and then proxy aga= in to the server (logging everything in between). In this case, I'm "wiret= apping", but I'm wiretapping myself. A TLS proxy is just a piece of technology, much like a microphone and a tap= e recorder. Legality depends on the use, not on technology. The use-case that interests me is deep firewall inspection. HTTP connection= s are routinely inspected by firewalls for downloaded malware, cross-site s= cripting, and various other attacks. Without a TLS proxy, HTTPS connections= can either slip under the radar or get blocked entirely. That would have b= een fine a few years ago, when SSL was only used for shopping and banking s= ites (you could defer your shopping and banking for when you were home). Th= ese days the use of HTTPS is becoming more prevalent, so blocking HTTPS is = no longer a good option. A TLS proxy allows an organization to use HTTPS wh= ile still applying company policy and defenses. I'm not saying this is all good. There are some real problems with using a = proxy: - The same technology can be used for wiretapping, and the user cannot tell= the difference between a good proxy and an evil one. - The client does not get to validate the server on its own (the subject dr= aft is an attempt to solve this) - Client certificates and PSK ciphersuites are broken. I think with a little modification the draft can solve the first two proble= ms. Yoav From thewirelessmacdude@yahoo.com Wed Aug 3 05:18:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E02921F8ACA for ; Wed, 3 Aug 2011 05:18:12 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJNNg1icWMUc for ; Wed, 3 Aug 2011 05:18:11 -0700 (PDT) Received: from nm16-vm0.bullet.mail.sp2.yahoo.com (nm16-vm0.bullet.mail.sp2.yahoo.com [98.139.91.210]) by ietfa.amsl.com (Postfix) with SMTP id E975F21F8ABE for ; Wed, 3 Aug 2011 05:18:11 -0700 (PDT) Received: from [98.139.91.66] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 12:18:23 -0000 Received: from [98.139.91.19] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 12:18:23 -0000 Received: from [127.0.0.1] by omp1019.mail.sp2.yahoo.com with NNFMP; 03 Aug 2011 12:18:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 942944.38808.bm@omp1019.mail.sp2.yahoo.com Received: (qmail 37342 invoked by uid 60001); 3 Aug 2011 12:18:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312373903; bh=PFY2+Q2Qj89m0LLnXVrEM6mmTPfvJGJbf7AKzd6QU/I=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=BJO4REvRg/pFLT3R5hwQFsfxc15uk9JY5CKqKygFPP4ZABFFX9v/JTzKPiQEVavzeA/iBRAULEzDlqZM4bx7CKg53rh3uZUQhkZs/aAFKfX+ZrS4DoAgI6yxKmgmsCW5j8hvvOEOZfSUiXfB4++hN6vi1U9YvC+np3hkOFnkDIc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=oFcPWaB2pTNr0hy/7SmLm2kIDpJ0dTG73BReOJ6Vcynn4obKJ3jcdIAlmFjTEfx1o5llGzqupxZHb1sN3gGeF06liiLWICK9125lVJ8TGhmTDg7DMNZCS9x32iNFFhaN1XxqC9gi1//tHdugnVNHj6rfVNNAxNo5qd9msd9I3Yk=; X-YMail-OSG: OrZDo1kVM1l3t5b8JarVC7fB6uMTupLtna_oWp395bZ0S9_ 09a7Vz3nnA26_6UeJ2gSwY2WlXhfbqpfWG_.Eu10Ki..nVita0Fd9f0viAnX aqPoeLev7a7Sri07SE5YSG_EJqIzVloj__XVmEHNaAGeVt_K6c_CTrJwyOYB hy2vwXCwaFYTB8zaDEpRUwQeGWfR26BtFqcbD5_bm5pSGQEartwvTERjMH4l FqlKBElhvcxeSxlY2cR9jaMZfonNnKWjXcAIBhLfE_gtoLHePDbcancfnZKW ww7fpOcLQTWoH_xuU5kC8BffxYmFmSAOTIm37TMmuO3f7Qz719a2nAjTEUl4 fCgXe4PJYnody_UdTTP5p39bUIbaHpuq68q6MTa4MphN11mlqroAK1lygURC NlZb68ZkUDuFiww-- Received: from [198.208.159.18] by web111718.mail.gq1.yahoo.com via HTTP; Wed, 03 Aug 2011 05:18:23 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.113.313619 Message-ID: <1312373903.421.YahooMailClassic@web111718.mail.gq1.yahoo.com> Date: Wed, 3 Aug 2011 05:18:23 -0700 (PDT) From: Ken Peirce To: "tls@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:18:12 -0000 Yoav, > The use-case that interests me is deep firewall inspection. > HTTP connections are routinely inspected by firewalls for > downloaded malware, cross-site scripting, and various other > attacks. Without a TLS proxy, HTTPS connections can either > slip under the radar or get blocked entirely. That would > have been fine a few years ago, when SSL was only used for > shopping and banking sites (you could defer your shopping > and banking for when you were home). These days the use of > HTTPS is becoming more prevalent, so blocking HTTPS is no > longer a good option. A TLS proxy allows an organization to > use HTTPS while still applying company policy and defenses. Why would you want to make banking and shopping less secure to support these other usage scenarios? The law enforcement community and service providers spend a lot of money to manage the security of their interception tools. There are many recorded cases where control of these tools was mishandled and abused by another party. TLS takes the human being out of the equation and protects the end user with known mathematical barriers. The TLS proxy exists today. It's two sessions in relay mode. The end user accepts the peer of the first session to be a trusted entity. If this trust is misplaced, that has nothing to do with the protocol. This is an application layer problem. Please ask the IETF leadership to form a new working group for a new protocol with this proxy as a fundamental tenet. You can experiment with this new protocol all you want. I do not want to see TLS broken because of tinkering in the name of some unestablished need. Ken From yaronf.ietf@gmail.com Wed Aug 3 06:07:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEDA21F8B3F for ; Wed, 3 Aug 2011 06:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.356 X-Spam-Level: X-Spam-Status: No, score=-103.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NmhLLhjZbKE for ; Wed, 3 Aug 2011 06:07:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF621F8AEC for ; Wed, 3 Aug 2011 06:07:20 -0700 (PDT) Received: by wyj26 with SMTP id 26so618164wyj.31 for ; Wed, 03 Aug 2011 06:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=0Rd19i8oMBNvrd1MQqiWOJXRZea9tj4nn19uvPvzpQk=; b=knVIE/ePHX1/TnW0bQM946KMEIQfbhGU6aBZtILvrQM9gJtKm++ZKgqz3AX4UiGQ/2 g8zjRcFeRBhVVHLp0Uv5Me1lG1Oq8mmpoXPfSpwMIcOp1hHGx4+e7zPRHdGwu4haU3yt KLjsc6mEly+00vCXwRUOSpTp6iI5EmUePkYuc= Received: by 10.227.208.132 with SMTP id gc4mr8656959wbb.48.1312376849989; Wed, 03 Aug 2011 06:07:29 -0700 (PDT) Received: from [10.0.0.6] (93-173-6-225.bb.netvision.net.il [93.173.6.225]) by mx.google.com with ESMTPS id gd1sm667030wbb.44.2011.08.03.06.07.28 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 06:07:29 -0700 (PDT) Message-ID: <4E39480F.4020105@gmail.com> Date: Wed, 03 Aug 2011 16:07:27 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] Read-only vs. read-write proxies (resent as plain text) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:07:21 -0000 First, I strongly dislike this type of corporate proxies, and would take the German constitutional regime any time. But in other free countries, this scenario is perfectly OK (legal and socially acceptable), and we need to cater for this use case. If we break the TLS architecture as proposed here, we will have killed forever any chance of TLS-level mutual authentication (TLS-PSK, TLS-SRP). This is IMHO too high a price for the benefits of R/W proxies. I have not been convinced by David's explanation of the need for R/W proxies, nor by Yoav's use case. A malware detection proxy can drop the connection precisely at the time malware is detected: the Word document would not be received in its entirety and would be rejected by the client. Even if a partial document is acceptable (e.g. JPEG), a partial malware is (hopefully) not effective. What are the reasons proxies need to modify the stream? - Purely informational app-level insertion, of the "sent from my iPhone" kind. The *client* has a trusted channel to the proxy, and if this is needed, the client can insert this stuff. - Security-specific signaling, of the "no spam detected here" kind. The server wouldn't trust the proxy with that anyway (this is a client-side proxy!) so this is not useful. - Malware detection: just ax the connection. - Other reasons? Lastly, it is important that the server should know of the proxy's presence, even if the indication relies on the client's and/or the proxy's good will. I can think of banks who still use passwords for client auth, but would not allow logins where that password is clearly intercepted by a third party. Thanks, Yaron From pgladstone@cisco.com Wed Aug 3 06:38:04 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139F721F8753 for ; Wed, 3 Aug 2011 06:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7CxiJfCIrbU for ; Wed, 3 Aug 2011 06:38:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 735F621F8686 for ; Wed, 3 Aug 2011 06:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=3917; q=dns/txt; s=iport; t=1312378695; x=1313588295; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=pVeS+BAKU3cVx9mRpW97Y5bmIpSLangJvH+/xl+Rvv0=; b=WnaQPzZIkgtPDuqE2F/q0SLw1+dalUDME+3geyEyEHd8PluybFrItN/P bGuSAIss2/mNY/4dTwzW5MkqRHxF+cla6QBRy6SjJvXRD1IsmjcdlKwyC 7yTR+VhnBzUemH71RbBBpx+BnpOY0f+PE+1H/VdvP086xWmUO5DCQ0IJP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAHABZOOU6rRDoG/2dsb2JhbAA5BgOER5QDjxZ3gUABAQEBAxIBEFUPAgsEFAkWCwICCQMCAQIBCTwTCAEBHqk1AY0rkT4CgyMZgXSBEASSe4UHi3k X-IronPort-AV: E=Sophos;i="4.67,310,1309737600"; d="scan'208,217";a="9230097" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 03 Aug 2011 13:38:15 +0000 Received: from [161.44.106.139] (dhcp-161-44-106-139.cisco.com [161.44.106.139]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73DcE47004030 for ; Wed, 3 Aug 2011 13:38:14 GMT Message-ID: <4E394F44.9070909@cisco.com> Date: Wed, 03 Aug 2011 09:38:12 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org References: <1312373903.421.YahooMailClassic@web111718.mail.gq1.yahoo.com> In-Reply-To: <1312373903.421.YahooMailClassic@web111718.mail.gq1.yahoo.com> Content-Type: multipart/alternative; boundary="------------080606020405000109090303" Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:38:04 -0000 This is a multi-part message in MIME format. --------------080606020405000109090303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/3/2011 8:18 AM, Ken Peirce wrote: > The TLS proxy exists today. It's two sessions in relay mode. The end user accepts the peer of the first session to be a trusted entity. If this trust is misplaced, that has nothing to do with the protocol. This is exactly true. The problem that we are trying to solve is to find out the actual identity of the server that the proxy has connected to. Further, we want the client to be able to validate the certificate of the server according to its own rules (which may include a different list of trusted root certificates). As people have pointed out, being able to understand the EV status of the remote server could be important. I think, based on the discussion, that there is a place for a new type of object in the TLS model -- the read-only proxy. This would require significant changes to the TLS protocol to support, and it might be significantly more difficult to implement than the current two TLS session approach. However, I suspect that until all proxies supported this new protocol, they would have to support the two TLS session model as well -- a viable strategy might be to try and negotiate the read-only proxy protocol and then fall back to the two TLS session model. Philip -- Philip Gladstone Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Ham radio: N1DQ --------------080606020405000109090303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

On 8/3/2011 8:18 AM, Ken Peirce wrote: 
The TLS proxy exists today. It's two sessions in relay mode. The end user accepts the peer of the first session to be a trusted entity. If this trust is misplaced, that has nothing to do with the protocol.

This is exactly true. The problem that we are trying to solve is to find out the actual identity of the server that the proxy has connected to. Further, we want the client to be able to validate the certificate of the server according to its own rules (which may include a different list of trusted root certificates). As people have pointed out, being able to understand the EV status of the remote server could be important.

I think, based on the discussion, that there is a place for a new type of object in the TLS model -- the read-only proxy. This would require significant changes to the TLS protocol to support, and it might be significantly more difficult to implement than the current two TLS session approach. However, I suspect that until all proxies supported this new protocol, they would have to support the two TLS session model as well -- a viable strategy might be to try and negotiate the read-only proxy protocol and then fall back to the two TLS session model.

Philip
-- 
Philip Gladstone
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Ham radio: N1DQ
--------------080606020405000109090303-- From paul@xelerance.com Wed Aug 3 08:13:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638E521F8B31 for ; Wed, 3 Aug 2011 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rI+5bi0aUZR for ; Wed, 3 Aug 2011 08:13:17 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1821F89CC for ; Wed, 3 Aug 2011 08:13:17 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5B484571A0; Wed, 3 Aug 2011 11:14:45 -0400 (EDT) Date: Wed, 3 Aug 2011 11:14:45 -0400 (EDT) From: Paul Wouters To: Nikos Mavrogiannopoulos In-Reply-To: <4E38E6C3.2030405@gnutls.org> Message-ID: References: <201108022010.p72KA7AI024538@fs4113.wdf.sap.corp> <4E38E6C3.2030405@gnutls.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:13:18 -0000 On Wed, 3 Aug 2011, Nikos Mavrogiannopoulos wrote: > On 08/03/2011 06:01 AM, Paul Wouters wrote: >> On Tue, 2 Aug 2011, Martin Rex wrote: >> >>> I find the idea of extending rfc6091 with a new certificate type >>> for raw keys more appealing that a completely new TLS extension. >> The TLS client still needs a way to convey this to the server, so that >> there is a migration path from full CA bundle to public key. That is, >> the client needs to be able to ask for "public key only" certificate type. >> So I believe we would still need a new TLS extension, but not a new TLS >> message type. > > And doesn't RFC6091 define the extension? Ah yes, it does. I would hope that the TLS WG would see enough of an interest to make a standard track extension though. 6091 is an Informational. Could the draft be rerwitten to use the 6091 cert type extension and still become a standards track document? Paul From marsh@extendedsubset.com Wed Aug 3 08:38:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E153B21F8BAB for ; Wed, 3 Aug 2011 08:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVgJCdhswI7g for ; Wed, 3 Aug 2011 08:38:42 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79621F8BAE for ; Wed, 3 Aug 2011 08:38:42 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QodX3-000EZy-VM; Wed, 03 Aug 2011 15:38:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C70DB6067; Wed, 3 Aug 2011 15:38:52 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+n4qIwX31GE8XJwdtnSgX3dHZT4j6m8bE= Message-ID: <4E396B8D.7090101@extendedsubset.com> Date: Wed, 03 Aug 2011 10:38:53 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Yaron Sheffer References: <4E38E69D.3000608@gmail.com> In-Reply-To: <4E38E69D.3000608@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Read-only vs. read-write proxies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:38:43 -0000 On 08/03/2011 01:11 AM, Yaron Sheffer wrote: > > I have not been convinced by David's explanation of the need for R/W > proxies, nor by Yoav's use case. A malware detection proxy can drop > the connection precisely at the time malware is detected [...] What > are the reasons proxies need to modify the stream? But isn't this distinction between RO and RW interception the kind of thing only a transport layer crypto engineer could consider meaningful? I mean, look at how authentication is handled on the web: form-submit passwords and secret session cookies. If the MitM in practice learns all the plaintext credentials of the end user, of what consolation is it to say that he couldn't actually modify some particular byte stream? "Other than that, Mrs. Lincoln, how did you like the play?" In Tunisia, for example, the attacker modified the web page only just enough to capture the credentials. His goal was to read the data in transit and the script injection was simply a means to that end. http://www.cpj.org/internet/2011/01/tunisia-invades-censors-facebook-other-accounts.php Perhaps there are protocols where it makes a meaningful difference, but for most stuff riding on TLS I'd wager that 3rd party decryption violates such fundamental assumptions that the overall system is effectively "pwned". - Marsh From yaronf.ietf@gmail.com Wed Aug 3 09:52:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007A521F8B50 for ; Wed, 3 Aug 2011 09:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV++S6uaSDWS for ; Wed, 3 Aug 2011 09:52:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 024D321F8B37 for ; Wed, 3 Aug 2011 09:52:28 -0700 (PDT) Received: by wyj26 with SMTP id 26so797637wyj.31 for ; Wed, 03 Aug 2011 09:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=z+pAWt5UscpMjgmDU4fQNL8CGk8+0Re5dWglN8DxzrE=; b=jHgmE/2jle7jLFx1JtuESWF3/xnq9wW4wcRfAtlGjB1jOaWok4dXBfPBBHMJ5lMSgn PS+bDZBIwxPchth7DRRBKyqcCWNbuDkL2C87df1voi4NdExHcQWhVKr6JsyH96QPgqWC st2dEgl42jQnIiEUjH9dclz/bu/TAeECb7Ds4= Received: by 10.227.174.142 with SMTP id t14mr2363858wbz.59.1312390360119; Wed, 03 Aug 2011 09:52:40 -0700 (PDT) Received: from [10.0.0.6] (93-173-6-225.bb.netvision.net.il [93.173.6.225]) by mx.google.com with ESMTPS id gb1sm817233wbb.54.2011.08.03.09.52.38 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 09:52:39 -0700 (PDT) Message-ID: <4E397CD4.5030004@gmail.com> Date: Wed, 03 Aug 2011 19:52:36 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Marsh Ray References: <4E38E69D.3000608@gmail.com> <4E396B8D.7090101@extendedsubset.com> In-Reply-To: <4E396B8D.7090101@extendedsubset.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Read-only vs. read-write proxies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:52:30 -0000 This is true, but we would like to move forward, possibly towards a future where mutual authentication is widely used. Either at the TLS level (similar to TLS-PSK and TLS-SRP), or at the HTTP or app level, as in the http-auth discussions. The first option would break with a RW proxy, but would work fine with a RO proxy. The second option would survive either one without being completely pwned - you don't get the credentials even if you get the date of the next anti-government demonstration. Then the question becomes: you trust this proxy to protect you from getting/sending malware. But do you also trust it to perform operations on your bank account? Thanks, Yaron On 08/03/2011 06:38 PM, Marsh Ray wrote: > On 08/03/2011 01:11 AM, Yaron Sheffer wrote: >> >> I have not been convinced by David's explanation of the need for R/W >> proxies, nor by Yoav's use case. A malware detection proxy can drop >> the connection precisely at the time malware is detected [...] What >> are the reasons proxies need to modify the stream? > > But isn't this distinction between RO and RW interception the kind of > thing only a transport layer crypto engineer could consider meaningful? > > I mean, look at how authentication is handled on the web: form-submit > passwords and secret session cookies. If the MitM in practice learns all > the plaintext credentials of the end user, of what consolation is it to > say that he couldn't actually modify some particular byte stream? > "Other than that, Mrs. Lincoln, how did you like the play?" > > In Tunisia, for example, > the attacker modified the web page only just enough to capture the > credentials. His goal was to read the data in transit and the script > injection was simply a means to that end. > http://www.cpj.org/internet/2011/01/tunisia-invades-censors-facebook-other-accounts.php > > > Perhaps there are protocols where it makes a meaningful difference, but > for most stuff riding on TLS I'd wager that 3rd party decryption > violates such fundamental assumptions that the overall system is > effectively "pwned". > > - Marsh From mrex@sap.com Wed Aug 3 11:22:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9522621F8ADE for ; Wed, 3 Aug 2011 11:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7ubrr1u2ox3 for ; Wed, 3 Aug 2011 11:22:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EEDC621F8ACC for ; Wed, 3 Aug 2011 11:22:32 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p73IMh9Q010241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 20:22:43 +0200 (MEST) From: Martin Rex Message-Id: <201108031822.p73IMg5I015846@fs4113.wdf.sap.corp> To: yaronf.ietf@gmail.com (Yaron Sheffer) Date: Wed, 3 Aug 2011 20:22:42 +0200 (MEST) In-Reply-To: <4E39480F.4020105@gmail.com> from "Yaron Sheffer" at Aug 3, 11 04:07:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Read-only vs. read-write proxies (resent as plain text) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:22:34 -0000 We do have server-side proxies ("reverse proxies") for TLS for at least 10 years, and they do not need to subvert TLS in an way in order to function. It is trivial to create similar client-side proxies for programmatic(!) clients where the client credentials are either held by or forwarded to the client proxy for all situations similar to the backend, where client and TLS client proxy are software components working under full control of the exact same entity. But having end users with personal, end-user credentials use a web browser on a machine that is so sensitive that it needs to be carefully watched is an extremely stupid idea ("gross negligence" in legal terms), that I do not think we should try to facilitate such stupid ideas in our protocols. The logical equivalent of a server-side reverse proxy would be a client-side remote desktop approach. On some platforms, this even works with PKI crypto tokens / smartcards. Sample scenario for Microsoft Windows, works with the installed base: - end user is in posession of a personalized PKI crypto token - end user uses "Remote Desktop / Microsoft Terminal Services Client" to dial from a sensitive machine into a monitored terminal server machine that is capable of accessing the internet - end user starts MSIE on terminal server and uses TLS client cert authentication with his PKI crypto token (access to the crypto token is forwared by Remote Desktop). Running the browser on a terminal server machine with local filtering/ monitoring is much more reasonable and resposible that accessing the internet with a web browser from a sensible machine, because the is not, and there never will be, a web browser without gaping security holes. -Martin PS: I don't know whether you listend to the IETF plenaries. In one of the studies it was reported, that the fraction of malware-infected client-machines that had an AV-product installed was higher than the fraction of malware-infected machines with no AV-product. (something which should not come as a surprise, and should be predictable from how the design of AV-solutions. AV-solutions are only statistically successful, being able to prevent old, known malware to spread further and cause epidemics/pandemics, but protect very poorly against new malware and targetted attacks (see Stuxnet). From mrex@sap.com Wed Aug 3 11:59:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71B211E808D for ; Wed, 3 Aug 2011 11:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.953 X-Spam-Level: X-Spam-Status: No, score=-9.953 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnZywdZT5Q7X for ; Wed, 3 Aug 2011 11:59:48 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3E11E807E for ; Wed, 3 Aug 2011 11:59:47 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p73Ixli7002075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 20:59:47 +0200 (MEST) From: Martin Rex Message-Id: <201108031859.p73Ixlin017760@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Wed, 3 Aug 2011 20:59:47 +0200 (MEST) In-Reply-To: from "Paul Wouters" at Aug 3, 11 11:14:45 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:59:48 -0000 Paul Wouters wrote: > > Nikos Mavrogiannopoulos wrote: > > > > Paul Wouters wrote: > > > > > > Martin Rex wrote: > > > > > > > I find the idea of extending rfc6091 with a new certificate type > > > > for raw keys more appealing that a completely new TLS extension. > > > > > > The TLS client still needs a way to convey this to the server, so that > > > there is a migration path from full CA bundle to public key. That is, > > > the client needs to be able to ask for "public key only" certificate type. > > > So I believe we would still need a new TLS extension, but not a new TLS > > > message type. > > > > And doesn't RFC6091 define the extension? > > Ah yes, it does. > > I would hope that the TLS WG would see enough of an interest to make > a standard track extension though. 6091 is an Informational. Could > the draft be rerwitten to use the 6091 cert type extension and still > become a standards track document? Huh? Why is that? "Informational" or "Experimental" is just fine! Weren't you complaining that your primary motiviator for this extension is to enable a TLS implementation without X.509? Personally, I would not consider a TLS implementation "generally useful" that has zero support for X.509 (not even X.509v1) (this is about implementations, not consumers!), but I'm pretty confident that TLS implementations without your extension likely continue to be "generally useful". So personally, I consider Informational or Experimental adequate for this proposal at the current time. It will always remain possible to submit a revised document for standards track in case that this technology attracts widespread adoption among implementors and consumers of the technology. PGP is a well-established alternative to X.509 and has been in active use for EMail and for signing software archives in Linux Distributions, and I don't see a problem with 6091 being Informational, either. -Martin From DPKemp@missi.ncsc.mil Wed Aug 3 13:55:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E7111E808C for ; Wed, 3 Aug 2011 13:55:48 -0700 (PDT) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB-lz4qiZUDu for ; Wed, 3 Aug 2011 13:55:48 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1312404948-28110-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1E11E807C for ; Wed, 3 Aug 2011 13:55:47 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p73KtwGj097211; Wed, 3 Aug 2011 16:55:58 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 16:56:07 -0400 Date: Wed, 3 Aug 2011 16:55:57 -0400 Message-ID: In-Reply-To: <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> References: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> From: "Kemp, David P." To: "David McGrew" , Cc: tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:55:48 -0000 This is a multi-part message in MIME format... ------------=_1312404948-28110-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1312404948-28110-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1E11E807C for ; Wed, 3 Aug 2011 13:55:47 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p73KtwGj097211; Wed, 3 Aug 2011 16:55:58 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 16:56:07 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC521F.BEB76807" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] TLS Proxy Server Extension Date: Wed, 3 Aug 2011 16:55:57 -0400 Message-ID: In-Reply-To: <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxQf2LNhmITZFa3Q7uDsf/+Uk2cgQBnAerQ References: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> From: "Kemp, David P." To: "David McGrew" , Cc: "Philip Gladstone" , X-OriginalArrivalTime: 03 Aug 2011 20:56:07.0953 (UTC) FILETIME=[C4683810:01CC521F] This is a multi-part message in MIME format. ------_=_NextPart_001_01CC521F.BEB76807 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: David McGrew > On Aug 1, 2011, at 9:15 AM, Martin Rex wrote: >> If the proxy terminates the clients >> TLS connection and establishes a new connection to the real server, >> then it will have to impersonate the real server to the client > > No, that's not right, at least not if "impersonate" is meant in the =20 > cryptographic sense. If "impersonate" is meant in the sense that a =20 > proxy can modify the traffic passing through it, then yes, that is a =20 > goal for the system; it is a requirement if TLS is to be used to =20 > protect communications when an HTTP proxy is present (for many types =20 > of proxies). A TLS connection between S and C provides integrity protection (which by definition is impossible without authentication): C knows that data it receives is identical to that sent by S. How do you propose to define roles that extend integrity properties to a three-party protocol? C must know that data it receives from S is sent by S, with no insertions or deletions. And that data it receives from P was sent by P with no insertions or deletions. "Modifying" traffic is fundamentally incompatible with data integrity - the concept is meaningless. There must be either two independent unmodifiable data streams between C and S and between C and P, or there must be a single stream between C and P, where C trusts P to be the data provider without knowing or caring where P got the data in the first place. That is what is meant by impersonation. In an application protocol it would be appropriate to tag sections of data that have different properties and originated from different sources - think chat room, or a portion-marked word document. TLS claims to protect an application-independent data stream - I have no idea how you define semantics of a 3-party "session" without becoming application-specific. Dave ------_=_NextPart_001_01CC521F.BEB76807 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjsUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAJQAAAFJFOiBbVExTXSBUTFMgUHJv eHkgU2VydmVyIEV4dGVuc2lvbgBlDAEFgAMADgAAANsHCAADABAANwA5AAMAcAEBIIADAA4AAADb BwgAAwAQADcAOgADAHEBAQmAAQAhAAAAMkRGN0IyMDE3OENEMzA0MjlBQTI3RDQ5OTA2NEJFMzIA GwcBA5AGAJgNAABGAAAACwACAAEAAAADACYAAAAAAAsAKwAAAAAAAwAuAAAAAAADADYAAAAAAEAA OQAwyle+H1LMAR4APQABAAAABQAAAFJFOiAAAAAAAgFHAAEAAAAzAAAAYz1VUzthPSA7cD1FeGNo YW5nZU5TQTtsPURBQkVDSy0xMTA4MDMyMDU1NThaLTYxOTcAAB4AcAABAAAAIQAAAFtUTFNdIFRM UyBQcm94eSBTZXJ2ZXIgRXh0ZW5zaW9uAAAAAAIBcQABAAAAGwAAAAHMUH9izYZiE2RWt0O7g7H/ /lJNnIEAZwHq0AAeABoMAQAAAA8AAABLZW1wLCBEYXZpZCBQLgAAHgAdDgEAAAAhAAAAW1RMU10g VExTIFByb3h5IFNlcnZlciBFeHRlbnNpb24AAAAAAgEJEAEAAAAcBQAAGAUAAKwIAABMWkZ1ptYt bgMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo 4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQ8wsJAWQzNhZQC6YK4wqE BR02RgNhOiBEYXakaWQF0GNHGCB3HPQIPiBPA6BBdWcgqDEsIAHQMSAhYQVAUDk6MTUQwE0gME2d CsB0C4AH8A7AIHcDYA0OsDofNR+QIElmICB0aGUgcANgeHl7I0AEkG0LgCCwB5EjUmOWbAiQAjBz IodUTAXweQWgbm4FkCGgAiAgoG5vHrAHkAGRJPBzI2AEIGHOICZQB+AmKXRvI0MYIKUHQCAUEHJ2 BJAsIofbI1EDoGkFQAPwbAMgE+DXKdAo0gdwcASQcwIgJFGfKQ4o1iTkHzUfNk5vIDBrI1AgsCcE IG4iQClAaehnaHQgk2wpYCcgMBPpBpAgIiv5IirgBCAHgH8AcDGBKMEjYRzlH5AFAHnFBTBvCcBh cGgN4CmR+QCAZS4jACMSMd8y6zUj7y+jJ8EztyOUYwORBGEGkPsj0SNhdDSwASA08QqwBBDfC4Ag ACNQA2Af8Ggq4S+SPSrBeQeQL5Q2sjh5Z28vKXECEC2RN5J5JyBlbY47KuI9IxggcXVpGCC/B4Az EiMwJeIysSjhYiNw/nUUEB6wKOE4mg6wJnAmEXhtbXUDADmAJoIEIHfDKrIDkUhUVFAjhTKx9yOQ B5BAUig+UgOBI9E0YDsHkTO3byMwI5IIkHMpmi4c+kEl3kFgdHcJ4fsGACbDQyOCHpEHkQuADrDf CcAq8CPQQqUmkihEEA3g/TvQYiPQAQELgCrwJpIysf0r8W87EQJgI3AD8CNQCGDfOFFPcCqxIaBD lCkeUErw2mswIHckgiCxZCCwJ9DjKvEYIGNlaSnQS4FLgX8BAE/zAyAo4yCxRaNNYVPdSDtIUPBN gCjweQhgI4L/TpEro02TKTEG8CRzILEOwf8J8B6wS6ssESGgJHIo8CfQWztxCeAtCrFMFW8XkT// IwBK8ENQMTFQ0lEvUjQDUv9KgTKxU+cgME8iMBEzMSmhv0O0BbEBADEAQ7M1cUEm4fdcD10YRMB3 MSBT12LBXs/5X94iTTnTOzE2oDp2MrFeZkNgYWBAQgdAbEUhbr9DIQqwIaBO5mFVS7ctJJR/AiBS IAUxMrU7MVcxYJJUfyNgGCBbVEFhUjAjUS2Rd/9kIgEALBBt0TMRQ2A5wwcw707iYWMnIClRbQQg ShZK8Pcm0kqUcCxQIDA+ZGxpb4H/a5NvlXFfRAJsYUrwOnBbcf8EIETAQTQjUmFjSxUFwE8m/1DS OzIFsTmABRA7QXWURMD/PgAFQHcHM0U6sBQABUALUf9SIGwDPPREEDz0MuRNYSv4+yaRSDtJREM0 wAtQQ4Vah/sq4whgbHFCf+JWAQchLIL9KPFhIAAUECZzZNEjMGFj9zgjK3M54WZsUTMRWNkm0v8F sDBwJDMesF1jhOgsQAhw71IgBCBqQguAayTQODIDYF8DcHJTd3EXwSaRLQDAcp5rQbFtkAsgVXFj dUBCf2wCJfILYW/xKOFCpn/MLfdtym9ZajFJK2RkEgEAJ9D/T1AH4FWyVqUUEAOBUAGDo/Un0DNa JSIUEDsRAiA2oF9PJkFgQyE7Mo2acywQY61u0WNIOx5xZRz0fZewHgA1EAEAAABBAAAAPEMxQTQ3 RjE1NDBERjMyNDZBOEQzMEM4NTNDMDVEMERBMDNERTI0QUNAREFCRUNLLm1pc3NpLm5jc2MubWls PgAAAAAeADkQAQAAAGMAAAA8MjAxMTA4MDExNjE1LnA3MUdGR01UMDE5NjEyQGZzNDExMy53ZGYu c2FwLmNvcnA+IDwyQTg4MjY5RC0zOEFGLTQ2OTUtOEREMC0wNTQzQzIzOTE0MjNAY2lzY28uY29t PgAAHgBCEAEAAAAxAAAAPDJBODgyNjlELTM4QUYtNDY5NS04REQwLTA1NDNDMjM5MTQyM0BjaXNj by5jb20+AAAAAAMAgBD/////HwDzEAEAAABWAAAAUgBFACUAMwBBACAAWwBUAEwAUwBdACAAVABM AFMAIABQAHIAbwB4AHkAIABTAGUAcgB2AGUAcgAgAEUAeAB0AGUAbgBzAGkAbwBuAC4ARQBNAEwA AAAAAAsA9hAAAAAAQAAHME2jsr4fUswBQAAIMNhTw74fUswBAgEQMAEAAABGAAAAAAAAAJJj8pZU /tMRo/gAgF8xnEUHAF5KQJejlNIRo8UAgF++yL8AAAFzXTwAAMsWET8I06VPmnxqPUhEoqcAAAJx KykAAAAAAwDeP59OAAADAPE/CQQAAB4A+D8BAAAADwAAAEtlbXAsIERhdmlkIFAuAAACAfk/AQAA AE0AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089RVhDSEFOR0VOU0EvT1U9TUlTU0kv Q049UkVDSVBJRU5UUy9DTj1EUEtFTVAxAAAAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJh dG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QE AAADABlAAAAAAAMAGkAAAAAAHgAwQAEAAAAIAAAARFBLRU1QMQAeADFAAQAAAAgAAABEUEtFTVAx AB4AOEABAAAACAAAAERQS0VNUDEAHgA5QAEAAAACAAAALgAAAAMAdkD/////AwAJWQEAAAADAAFu AAAAAAMAIYEDIAYAAAAAAMAAAAAAAABGAAAAAAGBAAAAAAAABQAigQMgBgAAAAAAwAAAAAAAAEYA AAAAAoEAAAAAAAAAAAAAAwAkgQMgBgAAAAAAwAAAAAAAAEYAAAAAE4EAAAEAAAALACWBAyAGAAAA AADAAAAAAAAARgAAAAAcgQAAAAAAAAsAJ4EDIAYAAAAAAMAAAAAAAABGAAAAACaBAAAAAAAAAwAp gQMgBgAAAAAAwAAAAAAAAEYAAAAAEIEAAAAAAAADACqBAyAGAAAAAADAAAAAAAAARgAAAAARgQAA AAAAAAMALYEDIAYAAAAAAMAAAAAAAABGAAAAACqBAAAAAAAAAwAwgQMgBgAAAAAAwAAAAAAAAEYA AAAAKYEAAAAAAAALADGBAyAGAAAAAADAAAAAAAAARgAAAAAkgQAAAAAAAAsAMoEDIAYAAAAAAMAA AAAAAABGAAAAACyBAAAAAAAAHgAzgQMgBgAAAAAAwAAAAAAAAEYAAAAAJ4EAAAEAAAABAAAAAAAA AAMANIEDIAYAAAAAAMAAAAAAAABGAAAAABKBAAABAAAAHgA1gQMgBgAAAAAAwAAAAAAAAEYAAAAA IYEAAAEAAAABAAAAAAAAAAsANoEDIAYAAAAAAMAAAAAAAABGAAAAAAOBAAAAAAAAAwA5gQMgBgAA AAAAwAAAAAAAAEYAAAAAI4EAAP///38LAIiBCCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMA 7YEIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwDygQggBgAAAAAAwAAAAAAAAEYAAAAAA4UA AAAAAAADAPyBCCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAA4IIIAYAAAAAAMAAAAAAAABG AAAAABiFAAAAAAAACwDsggggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAPCCCCAGAAAAAADA AAAAAAAARgAAAACChQAAAAAAAEAA7IMIIAYAAAAAAMAAAAAAAABGAAAAAL+FAACQIWK2H1LMAQsA KQAAAAAACwAjAAAAAAADAAYQ5PxfywMABxDBBQAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAA AEZST006REFWSURNQ0dSRVdPTkFVRzEsMjAxMSxBVDk6MTVBTSxNQVJUSU5SRVhXUk9URTpJRlRI RVBST1hZVEVSTUlOQVRFU1RIRUNMSUVOVFNUTFNDT05ORUNUSU9OQU5ERVMAAAAAAgF/AAEAAABB AAAAPEMxQTQ3RjE1NDBERjMyNDZBOEQzMEM4NTNDMDVEMERBMDNERTI0QUNAREFCRUNLLm1pc3Np Lm5jc2MubWlsPgAAAADVLw== ------_=_NextPart_001_01CC521F.BEB76807-- ------------=_1312404948-28110-1-- From mcgrew@cisco.com Wed Aug 3 14:36:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84A21F8581 for ; Wed, 3 Aug 2011 14:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.71 X-Spam-Level: X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-+RtE3OUbrj for ; Wed, 3 Aug 2011 14:36:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEAD21F857D for ; Wed, 3 Aug 2011 14:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2995; q=dns/txt; s=iport; t=1312407390; x=1313616990; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=jN2QXy8gXDdvJ4QfQbxlYgqcKGG8YMr1tzJjTZ8WMqI=; b=YFxSvZFtiinURxnPOjaipKlWE/IIyS3XRVahNx++9AtXqprSURJKanIW cm9uPAZFa2Yjp1/QVBLhuSVEm8iQgNvv0NGP+cdNTKCMNURqx3ADvLpKH L5La7crJVOZ/16xLN4E/3HZlT6Ej+FyuQaE8o8zFOxtvWve/TOxifzQUN Y=; X-IronPort-AV: E=Sophos;i="4.67,312,1309737600"; d="scan'208";a="9421431" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 03 Aug 2011 21:36:30 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73LaSWS002092; Wed, 3 Aug 2011 21:36:29 GMT Message-Id: From: David McGrew To: "Kemp, David P." In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Aug 2011 14:36:27 -0700 References: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> X-Mailer: Apple Mail (2.936) Cc: tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:36:18 -0000 On Aug 3, 2011, at 1:55 PM, Kemp, David P. wrote: > > > > From: David McGrew >> On Aug 1, 2011, at 9:15 AM, Martin Rex wrote: >>> If the proxy terminates the clients >>> TLS connection and establishes a new connection to the real server, >>> then it will have to impersonate the real server to the client >> >> No, that's not right, at least not if "impersonate" is meant in the >> cryptographic sense. If "impersonate" is meant in the sense that a >> proxy can modify the traffic passing through it, then yes, that is a >> goal for the system; it is a requirement if TLS is to be used to >> protect communications when an HTTP proxy is present (for many types >> of proxies). > > A TLS connection between S and C provides integrity protection > (which by > definition is impossible without authentication): C knows that data it > receives is identical to that sent by S. > > How do you propose to define roles that extend integrity properties > to a > three-party protocol? C must know that data it receives from S is > sent > by S, with no insertions or deletions. And that data it receives > from P > was sent by P with no insertions or deletions. "Modifying" traffic is > fundamentally incompatible with data integrity - the concept is > meaningless. There must be either two independent unmodifiable data > streams between C and S and between C and P, or there must be a single > stream between C and P, where C trusts P to be the data provider > without > knowing or caring where P got the data in the first place. That is > what > is meant by impersonation. > > In an application protocol it would be appropriate to tag sections of > data that have different properties and originated from different > sources - think chat room, or a portion-marked word document. TLS > claims to protect an application-independent data stream - I have no > idea how you define semantics of a 3-party "session" without becoming > application-specific. > > Dave The idea of authentication in which two or more parties are trusted to create authentication tags or signatures occurs in both crypto theory (group signatures and threshold signatures, for instance) and crypto standards (such as group authentication as defined in RFC 3740 and used in RFC 5374). Security models in which one party can modify data created by another can be sound and consistent, but of course we need to be careful about definitions, as you are pointing out. (As an extreme example, data aggregation in sensor networks allow many different senders to affect a single piece of data.) It would be most correct to describe the goals of the draft as establishing a pair of confidential and authenticated data streams between C/P and P/S, while having a three-party entitiy authentication. I think a good way to describe the goal would be: multiparty entity authentication with pairwise key establishment. David From yngve@opera.com Thu Aug 4 19:52:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA22321F859F for ; Thu, 4 Aug 2011 19:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoSLQJze9C3f for ; Thu, 4 Aug 2011 19:52:56 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0151521F8588 for ; Thu, 4 Aug 2011 19:52:55 -0700 (PDT) Received: from lessa-ii.oslo.os (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p752r0K7022433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Aug 2011 02:53:09 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "tls@ietf.org" Date: Fri, 05 Aug 2011 04:53:21 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: User-Agent: Opera Mail/10.62 (Win32) Subject: [TLS] Update about patching of the TLS Renego issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:52:57 -0000 Hello all, I just posted an update with more information about the status of patching the TLS Renego issue, this time concentrating on email server. -- 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 ralph-tls-tum@ralphholz.de Fri Aug 5 03:56:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41A921F8C1F for ; Fri, 5 Aug 2011 03:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQfVEw2PHUl8 for ; Fri, 5 Aug 2011 03:56:12 -0700 (PDT) Received: from serverkommune.de (serverkommune.de [88.198.12.136]) by ietfa.amsl.com (Postfix) with ESMTP id C1BE821F8C1D for ; Fri, 5 Aug 2011 03:56:11 -0700 (PDT) Received: (qmail 13233 invoked by uid 89); 5 Aug 2011 12:56:21 +0200 Received: from serverkommune.de (HELO ?131.159.20.131?) (ralph@serverkommune.de@88.198.12.136) by serverkommune.de with ESMTPA; 5 Aug 2011 12:56:21 +0200 Message-ID: <4E3BCC55.4000504@ralphholz.de> Date: Fri, 05 Aug 2011 12:56:21 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: tls@ietf.org References: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:56:12 -0000 Hi, > It would be most correct to describe the goals of the draft as > establishing a pair of confidential and authenticated data streams > between C/P and P/S, while having a three-party entitiy > authentication. I think a good way to describe the goal would be: > multiparty entity authentication with pairwise key establishment. On a related note, the following patent has just been brought to my attention: http://www.google.com/patents?id=MjTHAAAAEBAJ In essence, what is proposed is that a client consents to monitoring of its TLS connection. The assignee is Bluecoat - they sell TLS proxies, among other things. Ralph From robert.cragie@gridmerge.com Fri Aug 5 07:43:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C538B21F8B7C for ; Fri, 5 Aug 2011 07:43:45 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zROphjKrI-QY for ; Fri, 5 Aug 2011 07:43:44 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 987FB21F8B79 for ; Fri, 5 Aug 2011 07:43:42 -0700 (PDT) Received: from client-82-26-175-170.pete.adsl.virginmedia.com ([82.26.175.170] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QpLcu-0000JK-V8 for tls@ietf.org; Fri, 05 Aug 2011 15:43:53 +0100 Message-ID: <4E3C01FC.2060408@gridmerge.com> Date: Fri, 05 Aug 2011 15:45:16 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020508000106000309030301" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:43:45 -0000 This is a cryptographically signed message in MIME format. --------------ms020508000106000309030301 Content-Type: multipart/alternative; boundary="------------050600030003080003020204" This is a multi-part message in MIME format. --------------050600030003080003020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I would like to poke the coals on this one again too. There was a presentation at IETF80 regarding two drafts originating from = David McGrew (draft-mcgrew-tls-aes-ccm-01 and=20 draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC=20 there were no significant objections to this moving forward. However=20 there was no particular support from the WG chairs for doing this=20 through the WG. In the meantime, a number of vendors have been using=20 these drafts and testing the TLS_PSK_WITH_AES_128_CCM_8 and=20 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS and TLS forms=20 successfully. Therefore I would like to get an clear view as to the way to move this=20 forward - either through the WG or as individual submissions. Thanks Robert On 01/08/2011 10:13 PM, Thomas Herbst wrote: > Not sure where this fits into the wg chair's extensions triaging, but=20 > was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week. > > In Zigbee we'd specified ccm as most of the 802.15.4 chips have=20 > hardware support. > > tom > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------050600030003080003020204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to poke the coals on this one again too.

There was a presentation at IETF80 regarding two drafts originating from David McGrew (draft-mcgrew-tls-aes-ccm-01 and draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC there were no significant objections to this moving forward. However there was no particular support from the WG chairs for doing this through the WG. In the meantime, a number of vendors have been using these drafts and testing the TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS and TLS forms successfully.

Therefore I would like to get an clear view as to the way to move this forward - either through the WG or as individual submissions.
Thanks

Robert

On 01/08/2011 10:13 PM, Thomas Herbst wrote:
Not sure where this fits into the wg chair's extensions triaging, but was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week.

In Zigbee we'd specified ccm as most of the 802.15.4 chips have hardware support.

tom



_______________________________________________
TLS mailing list
TLS@ie=
tf.org
https://www.ietf.org/mailman/listinfo/tls
--------------050600030003080003020204-- --------------ms020508000106000309030301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK0DCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMYIEYDCCBFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMAkGBSsOAwIaBQCgggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTExMDgwNTE0NDUxNlowIwYJKoZIhvcNAQkEMRYEFMj939WPk2+5pDcKtfvx CdcDjLU2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJ KwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNV BAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1D bGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYL KoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UE BxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0 LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0G CSqGSIb3DQEBAQUABIIBAEYcvhSe3CBvWhyXZRd5Fa1NCWxTOqQxquR78idmzMM7+eRvP3XO rIgKoXZOY6I7vQkhcdyiSUUXi/2BpGoISZxRs+BIIgRrRykxyeoZ96i9FDFBw6eZZy3RfT4F qIUn7ecSdllMwvcRhasHhRu/+HhhV5ijjmWLTWZ0azKhF7MXWk9j9UJ6YMjPOhB5MaQVhfds OZzEDRtMLAYss4/cGdRlwIlLZVUeDnHlrZN/yr1XjqI8QkwO+vZ5q4kRHIZ5PBucaZV9khr+ w4hLcdBzC0T3eEXL0zIxbQhCnaOywtpg+DrN/1xkz2McVNERBLTbTEc3gIQmpM5IrGZ1sQW4 MsIAAAAAAAA= --------------ms020508000106000309030301-- From jsalowey@cisco.com Fri Aug 5 08:47:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE1D21F8B10 for ; Fri, 5 Aug 2011 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.137 X-Spam-Level: X-Spam-Status: No, score=-104.137 tagged_above=-999 required=5 tests=[AWL=-1.538, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDRNZBBfvy+V for ; Fri, 5 Aug 2011 08:47:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3126821F8AFE for ; Fri, 5 Aug 2011 08:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2006; q=dns/txt; s=iport; t=1312559261; x=1313768861; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HcSM2ArQEdjo//iJ0H7absLigtKts8GHhcmvXNE5H5g=; b=B8Gwr3ZNQ9fAENMQ2lqUKNeQk3/gSif+PZIvxNXG9nf7XFRwOQTKwxO7 8w3EsdoygadZ5nWbZ4k/41Tzj9l03K/vRDmgZlKN54tyDWpgs0xs+Vz8r RI2ogVGMQlB/z9UvtUcVSMRdLhgpfTRbYV6SBlAZ1HoDwrJTkTTxemF2v s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUHAJUPPE6rRDoJ/2dsb2JhbABCmF2PB3eBQAEBAQECAQEBAQ8BJzQLBQsLGC4nMBkih0sEoCEBnnGFZ18Eh1yLJYUIi38 X-IronPort-AV: E=Sophos;i="4.67,323,1309737600"; d="scan'208";a="10109808" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 05 Aug 2011 15:47:39 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p75FlbtT018055; Fri, 5 Aug 2011 15:47:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4E3C01FC.2060408@gridmerge.com> Date: Fri, 5 Aug 2011 08:47:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E3C01FC.2060408@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 15:47:24 -0000 Where we left this was there was some, but not overwhelming support to = bring it into the working group. It was left to the authors on which = path to take, through the working group process or as an individual = submission. If you go through the working group it is more likely = there will be changes than if you go the individual submission route. = Matthew also raised the question of standards track vs information for = ECC cipher suites. For ECC, I still believe that informational will be = the most expedient. =20 Joe On Aug 5, 2011, at 7:45 AM, Robert Cragie wrote: > I would like to poke the coals on this one again too. >=20 > There was a presentation at IETF80 regarding two drafts originating = from David McGrew (draft-mcgrew-tls-aes-ccm-01 and = draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC = there were no significant objections to this moving forward. However = there was no particular support from the WG chairs for doing this = through the WG. In the meantime, a number of vendors have been using = these drafts and testing the TLS_PSK_WITH_AES_128_CCM_8 and = TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS and TLS forms = successfully. >=20 > Therefore I would like to get an clear view as to the way to move this = forward - either through the WG or as individual submissions. >=20 > Thanks >=20 > Robert >=20 > On 01/08/2011 10:13 PM, Thomas Herbst wrote: >> Not sure where this fits into the wg chair's extensions triaging, but = was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week. >>=20 >> In Zigbee we'd specified ccm as most of the 802.15.4 chips have = hardware support. >>=20 >> tom >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >>=20 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From rstruik.ext@gmail.com Fri Aug 5 09:36:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96B621F8BFB for ; Fri, 5 Aug 2011 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eTYZW7Q1A3r for ; Fri, 5 Aug 2011 09:36:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B58421F8B8D for ; Fri, 5 Aug 2011 09:36:16 -0700 (PDT) Received: by gyd5 with SMTP id 5so2051946gyd.31 for ; Fri, 05 Aug 2011 09:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=aTxFGJyrCBzNGpFWfgFatjIniCRiVFuh7cKeI/sikXc=; b=RG4BvYvDBpCLy72dxlxOLGufZZXEvdVX/X1WCDhoOrXT3lecHJ4t37JAptvnPqGPob BpYBTyZj6uVBknuyfaX4J4e3JD4pelr4Dn9B+XjaCBbbnoSKmsJhIMeAbk2mDvgR2oXE HopQxeJ2/F+0gA1/jJ3+4V894NMD3taary8sg= Received: by 10.236.181.193 with SMTP id l41mr911259yhm.80.1312562192920; Fri, 05 Aug 2011 09:36:32 -0700 (PDT) Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.231.117.243]) by mx.google.com with ESMTPS id o2sm3020262yhl.29.2011.08.05.09.36.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 09:36:31 -0700 (PDT) Message-ID: <4E3C1C06.1040801@gmail.com> Date: Fri, 05 Aug 2011 12:36:22 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Salowey References: <4E3C01FC.2060408@gridmerge.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 16:36:16 -0000 Dear colleagues: It would help if one could elaborate somewhat more on some of the implicit design decisions underlying those internet drafts. Example: The nonce construction with the CCM mode in the drafts seems to be incompatible with that suggested with 802.15.4-2006 (as mentioned in the introduction and, presumably, to be used with ZigBee SE2.0). If so, this suggests one has to segregate key management for the MAC (if using 802.15.4) and for higher layers, including the management of counters used with the CCM mode of operation. Best regards, Rene On 05/08/2011 11:47 AM, Joe Salowey wrote: > Where we left this was there was some, but not overwhelming support to bring it into the working group. It was left to the authors on which path to take, through the working group process or as an individual submission. If you go through the working group it is more likely there will be changes than if you go the individual submission route. Matthew also raised the question of standards track vs information for ECC cipher suites. For ECC, I still believe that informational will be the most expedient. > > Joe > On Aug 5, 2011, at 7:45 AM, Robert Cragie wrote: > >> I would like to poke the coals on this one again too. >> >> There was a presentation at IETF80 regarding two drafts originating from David McGrew (draft-mcgrew-tls-aes-ccm-01 and draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC there were no significant objections to this moving forward. However there was no particular support from the WG chairs for doing this through the WG. In the meantime, a number of vendors have been using these drafts and testing the TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS and TLS forms successfully. >> >> Therefore I would like to get an clear view as to the way to move this forward - either through the WG or as individual submissions. >> >> Thanks >> >> Robert >> >> On 01/08/2011 10:13 PM, Thomas Herbst wrote: >>> Not sure where this fits into the wg chair's extensions triaging, but was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week. >>> >>> In Zigbee we'd specified ccm as most of the 802.15.4 chips have hardware support. >>> >>> tom >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From d.sturek@att.net Fri Aug 5 09:42:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769F521F8C45 for ; Fri, 5 Aug 2011 09:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL9LHo3K3N5F for ; Fri, 5 Aug 2011 09:42:33 -0700 (PDT) Received: from nm8.access.bullet.mail.sp2.yahoo.com (nm8.access.bullet.mail.sp2.yahoo.com [98.139.44.135]) by ietfa.amsl.com (Postfix) with SMTP id E17A621F8C44 for ; Fri, 5 Aug 2011 09:42:33 -0700 (PDT) Received: from [98.139.44.98] by nm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 16:42:48 -0000 Received: from [98.139.44.84] by tm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 16:42:48 -0000 Received: from [127.0.0.1] by omp1021.access.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 16:42:48 -0000 X-Yahoo-Newman-Id: 765056.60771.bm@omp1021.access.mail.sp2.yahoo.com Received: (qmail 13151 invoked from network); 5 Aug 2011 16:42:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1312562567; bh=f/wsmtePo34LvHrhWVmBhq7TC4ZOsfJrb5caKdz2aws=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=E7XNpoLAymbbHoUBrsNNn5CVduvhY/PEQlLR2+vQa44PRrmQ/6LJNNvIhR76/epy9+NaJtWI1YT47licEbILOfZSgnonxUx/S3kOmRKZeEFpFMxTyY8FUJb4258NkK1yY7Agt3bY4JhqjYdMHDaLsO578LQQcRkKCVaYYstHGZg= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7357NzgVM1mvNxHjJbWNcd3vxYUigEQy_SXZTsmW2jXHFe4 zs9GJILy9PN7B45Tkrp6fdF1NUyI2Mzb3BI166Z_6YV1BaVKlJut4GdQM3g_ WmFooFWFsfHMBaf4pelcI1pNp_cixvVMciLIvKBmfywuX.P1_dvZbNtIcbmc 26McNub3Vtp4GLheIBYJm3Oj9RJ1v7mtb6AFQ..KpDsBL3DM7spufK._OSDu 7raZOEVEvIKcHBysPcQXFDSiQZXSDMpOxPNGwBmFPEDHuvyLZag_6.tLoO6L JcYwr6Cr0eA9yxSturY4BsPxfchWYNs192kg5yuUHkldMskG.UitH6JfT75p VAJhfLvyazABUskdAPZUJnSqqxHBzl5xdFyzPFNYnPjVDivZkg6DBLp9vw2B UIn8- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.103] (d.sturek@174.78.56.227 with login) by smtp102.sbc.mail.gq1.yahoo.com with SMTP; 05 Aug 2011 09:42:46 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 05 Aug 2011 09:42:42 -0700 From: Don Sturek To: Rene Struik , Joe Salowey Message-ID: Thread-Topic: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 In-Reply-To: <4E3C1C06.1040801@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 16:42:34 -0000 Hi Rene, Can you elaborate on the issue around this topic "If so, this suggests one has to segregate key management for the MAC (if using 802.15.4) and for higher layers, including the management of counters used with the CCM mode of operation."? On the surface, segregating key management for the MAC from the higher layers seems like the *right* thing to do! Don On 8/5/11 9:36 AM, "Rene Struik" wrote: >Dear colleagues: > >It would help if one could elaborate somewhat more on some of the >implicit design decisions underlying those internet drafts. > >Example: >The nonce construction with the CCM mode in the drafts seems to be >incompatible with that suggested with 802.15.4-2006 (as mentioned in the >introduction and, presumably, to be used with ZigBee SE2.0). If so, >this suggests one has to segregate key management for the MAC (if using >802.15.4) and for higher layers, including the management of counters >used with the CCM mode of operation. > >Best regards, Rene > >On 05/08/2011 11:47 AM, Joe Salowey wrote: >> Where we left this was there was some, but not overwhelming support to >>bring it into the working group. It was left to the authors on which >>path to take, through the working group process or as an individual >>submission. If you go through the working group it is more likely >>there will be changes than if you go the individual submission route. >>Matthew also raised the question of standards track vs information for >>ECC cipher suites. For ECC, I still believe that informational will be >>the most expedient. >> >> Joe >> On Aug 5, 2011, at 7:45 AM, Robert Cragie wrote: >> >>> I would like to poke the coals on this one again too. >>> >>> There was a presentation at IETF80 regarding two drafts originating >>>from David McGrew (draft-mcgrew-tls-aes-ccm-01 and >>>draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC >>>there were no significant objections to this moving forward. However >>>there was no particular support from the WG chairs for doing this >>>through the WG. In the meantime, a number of vendors have been using >>>these drafts and testing the TLS_PSK_WITH_AES_128_CCM_8 and >>>TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS and TLS forms >>>successfully. >>> >>> Therefore I would like to get an clear view as to the way to move this >>>forward - either through the WG or as individual submissions. >>> >>> Thanks >>> >>> Robert >>> >>> On 01/08/2011 10:13 PM, Thomas Herbst wrote: >>>> Not sure where this fits into the wg chair's extensions triaging, but >>>>was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week. >>>> >>>> In Zigbee we'd specified ccm as most of the 802.15.4 chips have >>>>hardware support. >>>> >>>> tom >>>> >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > >-- >email: rstruik.ext@gmail.com >Skype: rstruik >cell: +1 (647) 867-5658 >USA Google voice: +1 (415) 690-7363 > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From robert.cragie@gridmerge.com Fri Aug 5 10:58:06 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C577311E8070 for ; Fri, 5 Aug 2011 10:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyPra89f8RFm for ; Fri, 5 Aug 2011 10:58:06 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id C29E921F886C for ; Fri, 5 Aug 2011 10:58:05 -0700 (PDT) Received: from client-82-26-175-170.pete.adsl.virginmedia.com ([82.26.175.170] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) id 1QpOex-00013E-BX; Fri, 05 Aug 2011 18:58:11 +0100 Message-ID: <4E3C2F86.1090303@gridmerge.com> Date: Fri, 05 Aug 2011 18:59:34 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Rene Struik References: <4E3C01FC.2060408@gridmerge.com> <4E3C1C06.1040801@gmail.com> In-Reply-To: <4E3C1C06.1040801@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080204070406070803000808" X-Authenticated-As: robert.cragie@gridmerge.com Cc: tls@ietf.org Subject: Re: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:58:06 -0000 This is a cryptographically signed message in MIME format. --------------ms080204070406070803000808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rene, It's not an issue. The CCM mode used in the drafts is not the same as=20 that in 802.15.4 and that was quite deliberate; there was never an=20 intent to make this specific to 802.15.4, more that it was recognized=20 that 802.15.4 devices use CCM mode therefore this can be leveraged=20 efficiently for TLS implementations. Key management for the TLS use is=20 distinct from the key management of the MAC security material - I can't=20 see why you would ever want to commonize frame counters across layers. Robert On 05/08/2011 5:36 PM, Rene Struik wrote: > Dear colleagues: > > It would help if one could elaborate somewhat more on some of the > implicit design decisions underlying those internet drafts. > > Example: > The nonce construction with the CCM mode in the drafts seems to be > incompatible with that suggested with 802.15.4-2006 (as mentioned in th= e > introduction and, presumably, to be used with ZigBee SE2.0). If so, > this suggests one has to segregate key management for the MAC (if using= > 802.15.4) and for higher layers, including the management of counters > used with the CCM mode of operation. > > Best regards, Rene > > On 05/08/2011 11:47 AM, Joe Salowey wrote: >> Where we left this was there was some, but not overwhelming support to= bring it into the working group. It was left to the authors on which pa= th to take, through the working group process or as an individual submiss= ion. If you go through the working group it is more likely there will b= e changes than if you go the individual submission route. Matthew also = raised the question of standards track vs information for ECC cipher suit= es. For ECC, I still believe that informational will be the most expedi= ent. >> >> Joe >> On Aug 5, 2011, at 7:45 AM, Robert Cragie wrote: >> >>> I would like to poke the coals on this one again too. >>> >>> There was a presentation at IETF80 regarding two drafts originating f= rom David McGrew (draft-mcgrew-tls-aes-ccm-01 and draft-mcgrew-tls-aes-cc= m-ecc-01) given by Matthew Campagna and IIRC there were no significant ob= jections to this moving forward. However there was no particular support = from the WG chairs for doing this through the WG. In the meantime, a numb= er of vendors have been using these drafts and testing the TLS_PSK_WITH_A= ES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 in both PANA/EAP-TLS = and TLS forms successfully. >>> >>> Therefore I would like to get an clear view as to the way to move thi= s forward - either through the WG or as individual submissions. >>> >>> Thanks >>> >>> Robert >>> >>> On 01/08/2011 10:13 PM, Thomas Herbst wrote: >>>> Not sure where this fits into the wg chair's extensions triaging, bu= t was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last week. >>>> >>>> In Zigbee we'd specified ccm as most of the 802.15.4 chips have hard= ware support. >>>> >>>> tom >>>> >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > --------------ms080204070406070803000808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK0DCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMYIEYDCCBFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMAkGBSsOAwIaBQCgggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTExMDgwNTE3NTkzNFowIwYJKoZIhvcNAQkEMRYEFI2IBZYAqxCsQFZTqRKe KbAlFfkUMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJ KwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNV BAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1D bGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYL KoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UE BxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0 LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0G CSqGSIb3DQEBAQUABIIBAIxU/jupue7jHh8TJ7+OlUrzKl93OaU62N+Rr2FlSeWtc3004Rqv Q4r4NPLaP8/9AID1FAANfxXxz4a//QRWZhrDmwQzNn09x+s85ru158RhBFVDd6tkwdrnqOp4 YsmQXzRsNfHbeeSIabemlFMknmWGrbf2TW8+Ts+A4PzsXgQehj6lromt5A0Shq85tdvWEOjS O03HRo+HeVRw50xkAb+RlIQ1uANbPYaY8tuGitSKsuOM1l9GO+VmMcKvAhp6Gi3ROqLYgg/I AAS/ZX9ag/AaaJIgRrbVdE/9GjmntxEZSUIkc4pgc3JoTbIP5LejZRvYXeSl3Prwm+i4feEO ytQAAAAAAAA= --------------ms080204070406070803000808-- From rstruik.ext@gmail.com Fri Aug 5 13:42:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A288E11E80C1 for ; Fri, 5 Aug 2011 13:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF8OqC7OYYFQ for ; Fri, 5 Aug 2011 13:42:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABB9911E80B2 for ; Fri, 5 Aug 2011 13:42:08 -0700 (PDT) Received: by gyd5 with SMTP id 5so2196893gyd.31 for ; Fri, 05 Aug 2011 13:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=+z6Sn1fdfoIYYAt+yLUbDujzkVtGnYogB+nyQMctzf0=; b=d/HSv3Ogn6VMhcPO0gq7sbAvMDNhQmwrDOy52NH03IP48Utu4w827tDqjj6okAiF9v 3wq1IFRfBn8eKntQAMpLHw+PsSuEqcazqUGt9W7Y31Qq7AUWK6eTcqgD3Oq8Nw+i583S /xZEYeY+/m4uM4d5+Tx5f1Y7HT7WpeU/oi2PM= Received: by 10.91.26.30 with SMTP id d30mr2416962agj.64.1312576945991; Fri, 05 Aug 2011 13:42:25 -0700 (PDT) Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.231.117.243]) by mx.google.com with ESMTPS id h15sm2614201ank.13.2011.08.05.13.42.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 13:42:25 -0700 (PDT) Message-ID: <4E3C55AC.2050608@gmail.com> Date: Fri, 05 Aug 2011 16:42:20 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <4E3C01FC.2060408@gridmerge.com> <4E3C1C06.1040801@gmail.com> <4E3C2F86.1090303@gridmerge.com> In-Reply-To: <4E3C2F86.1090303@gridmerge.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] working group discussion of draft-mcgrew-tls-aes-ccm-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:42:09 -0000 Hi Robert: I do appreciate that one should not just tailor towards the 802.15.4 MAC and make this more agnostic w.r.t. lower layers. Nevertheless, I was just curious whether the design choices have the *potential* to work together with, e.g., 802.15.4 and realize an implementation that minimizes the state one has to keep on a device. This minimum would be one key and one counter per incoming device, irrespective of layer. In fact, the "one counter per incoming device" could be reduced to "one loosely synchronized notion of time" instead, thereby reducing state to one key and one loosely synchronized clock. It is not clear to me whether, with the I-Ds, one can get close to this. Best regards, Rene On 05/08/2011 1:59 PM, Robert Cragie wrote: > Hi Rene, > > It's not an issue. The CCM mode used in the drafts is not the same as > that in 802.15.4 and that was quite deliberate; there was never an > intent to make this specific to 802.15.4, more that it was recognized > that 802.15.4 devices use CCM mode therefore this can be leveraged > efficiently for TLS implementations. Key management for the TLS use is > distinct from the key management of the MAC security material - I > can't see why you would ever want to commonize frame counters across > layers. > > Robert > > On 05/08/2011 5:36 PM, Rene Struik wrote: >> Dear colleagues: >> >> It would help if one could elaborate somewhat more on some of the >> implicit design decisions underlying those internet drafts. >> >> Example: >> The nonce construction with the CCM mode in the drafts seems to be >> incompatible with that suggested with 802.15.4-2006 (as mentioned in the >> introduction and, presumably, to be used with ZigBee SE2.0). If so, >> this suggests one has to segregate key management for the MAC (if using >> 802.15.4) and for higher layers, including the management of counters >> used with the CCM mode of operation. >> >> Best regards, Rene >> >> On 05/08/2011 11:47 AM, Joe Salowey wrote: >>> Where we left this was there was some, but not overwhelming support >>> to bring it into the working group. It was left to the authors on >>> which path to take, through the working group process or as an >>> individual submission. If you go through the working group it is >>> more likely there will be changes than if you go the individual >>> submission route. Matthew also raised the question of standards >>> track vs information for ECC cipher suites. For ECC, I still >>> believe that informational will be the most expedient. >>> >>> Joe >>> On Aug 5, 2011, at 7:45 AM, Robert Cragie wrote: >>> >>>> I would like to poke the coals on this one again too. >>>> >>>> There was a presentation at IETF80 regarding two drafts originating >>>> from David McGrew (draft-mcgrew-tls-aes-ccm-01 and >>>> draft-mcgrew-tls-aes-ccm-ecc-01) given by Matthew Campagna and IIRC >>>> there were no significant objections to this moving forward. >>>> However there was no particular support from the WG chairs for >>>> doing this through the WG. In the meantime, a number of vendors >>>> have been using these drafts and testing the >>>> TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 >>>> in both PANA/EAP-TLS and TLS forms successfully. >>>> >>>> Therefore I would like to get an clear view as to the way to move >>>> this forward - either through the WG or as individual submissions. >>>> >>>> Thanks >>>> >>>> Robert >>>> >>>> On 01/08/2011 10:13 PM, Thomas Herbst wrote: >>>>> Not sure where this fits into the wg chair's extensions triaging, >>>>> but was hoping for an update on draft-mcgrew-tls-aes-ccm-01 last >>>>> week. >>>>> >>>>> In Zigbee we'd specified ccm as most of the 802.15.4 chips have >>>>> hardware support. >>>>> >>>>> tom >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From turners@ieca.com Fri Aug 12 17:01:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8F421F8AFB for ; Fri, 12 Aug 2011 17:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF1zUhWjBfuN for ; Fri, 12 Aug 2011 17:01:15 -0700 (PDT) Received: from nm27.access.bullet.mail.mud.yahoo.com (nm27.access.bullet.mail.mud.yahoo.com [66.94.237.92]) by ietfa.amsl.com (Postfix) with SMTP id 8428021F8AEA for ; Fri, 12 Aug 2011 17:01:15 -0700 (PDT) Received: from [66.94.237.198] by nm27.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Aug 2011 00:01:50 -0000 Received: from [98.139.221.60] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Aug 2011 00:01:50 -0000 Received: from [127.0.0.1] by smtp101.biz.mail.bf1.yahoo.com with NNFMP; 13 Aug 2011 00:01:50 -0000 X-Yahoo-Newman-Id: 812411.65518.bm@smtp101.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _Y7yIicVM1nmNtV9HWmf1fOf3TYT.IhZsGWm0TS73Rghxx5 jgKO_KGjBrH.yK_TEc3muVoOA7omEOpoKu3yc4IddAagHyZXbntr58M1BbWS uR37wQStb5NEDSxgFykrCB3Rieg6YkdXHTw0xkComk2VhjpirdxA6fDucPo7 svsEy0cjPpT6CD_35pKtw4uy9.5u5t4nO5zSqBZWXXH.up3UDkVd0EeMDHR8 Bn6WaqbecqZVpKLzM7MUnW_fO4ka9oSYIMQxaLvgUj_YqDsnooEjABqDZkmZ 42rmLyYl6WBaji9tEttunVWTKFbbOHoNWnxaJc_P5ewTtn0OuXsje4C0gHHw xgBQTK8xQvLdOtfOQcXyZa.YDe5dbHVzKZ0wheTD23LI6Aww0XuOPFefZbXL cyzWxQQQmdS3QpaSCpx0I X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@71.191.5.115 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 12 Aug 2011 17:01:50 -0700 PDT Message-ID: <4E45BEED.4030200@ieca.com> Date: Fri, 12 Aug 2011 20:01:49 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20110812235701.91C6698C221@rfc-editor.org> In-Reply-To: <20110812235701.91C6698C221@rfc-editor.org> X-Forwarded-Message-Id: <20110812235701.91C6698C221@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] Fwd: RFC 6101 on The Secure Sockets Layer (SSL) Protocol Version 3.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Aug 2011 00:01:16 -0000 FYI... -------- Original Message -------- Subject: RFC 6101 on The Secure Sockets Layer (SSL) Protocol Version 3.0 Date: Fri, 12 Aug 2011 16:57:01 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6101 Title: The Secure Sockets Layer (SSL) Protocol Version 3.0 Author: A. Freier, P. Karlton, P. Kocher Status: Historic Stream: IETF Date: August 2011 Mailbox: nikos.mavrogiannopoulos@esat.kuleuven.be Pages: 67 Characters: 142297 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-mavrogiannopoulos-ssl-version3-06.txt URL: http://www.rfc-editor.org/rfc/rfc6101.txt This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows. This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community. HISTORIC: This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From bsmith@mozilla.com Sat Aug 20 03:45:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741C721F8744 for ; Sat, 20 Aug 2011 03:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glAN6HHyzHU1 for ; Sat, 20 Aug 2011 03:45:05 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1180D21F871C for ; Sat, 20 Aug 2011 03:45:05 -0700 (PDT) Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id 25BF8AE647B0; Sat, 20 Aug 2011 03:46:04 -0700 (PDT) Date: Sat, 20 Aug 2011 03:46:04 -0700 (PDT) From: Brian Smith To: Eric Rescorla Message-ID: <1360415263.273856.1313837164056.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.140.149.214] X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-agl-tls-nextproto-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 20 Aug 2011 10:45:05 -0000 Eric Rescorla wrote: > MOTIVATION > It's unclear from the draft what the motivation for this work is. Practically, it allows multiple protocols to be offered on the same host:port. In particular, it allows SPDY and HTTP to both use port 443. Mozilla will use this extension (or the previous version) for exactly this purpose. In addition, I think we will also eventually use it for all of our TLS-based communication, to reduce the risk of cross-protocol attacks. > However, WebSockets does not use NPN; the HyBi working group > explicitly rejected NPN because it would have required the use of TLS > at all times. I'm not saying I agree with this, but it's what > happened. Instead, the HyBi WG designed their own application-layer > handshake which is intended to thwart cross-protocol > attacks. Similarly, the other major WG which is currently concerned > with cross-protocol attacks, WebRTC, is not interested in NPN but > rather is using an ICE-based handshake prior to sending traffic. What > IETF protocols have a demand for this functionality? SMTP, HTTP, IMAP, WebSockets. (There are email providers that offer IMAPS and SMTPS over port 443.) > ENCRYPTED NEGOTIATION > This document specifies a partially encrypted negotiation mechanism: > the server advertises some set of protocols (in the ServerHello) > and the client specifies a specific protocol (in a separate > handshake message inserted between the CCS and the Finished). > The client's announcement need not match any of the protocols > specified by the server. Thus, the negotiation is partly encrypted. > > The reason for this appears to be that this mechanism is designed to > prevent network attackers from learning which next protocol is being > requested. (See Section 4). I'm extremely skeptical of this objective: > This wouldn't be a big deal except that this highly imperfect > functionality comes at significant architectural cost. This mechanism > is clearly more invasive and complicated than necessary to accomplish > the goal of addressing cross-protocol attacks. We should not send data unprotected when we can send it protected. I think this is a more important design goal. We could generalize the mechanism so that the new message consists of a sequence of TLS extensions, to avoid creating new message types in the future. Cheers, Brian From jsalowey@cisco.com Sun Aug 21 22:07:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1EC21F86F6 for ; Sun, 21 Aug 2011 22:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0n4ij-dcTys for ; Sun, 21 Aug 2011 22:07:17 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2106F21F86DF for ; Sun, 21 Aug 2011 22:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=159; q=dns/txt; s=iport; t=1313989701; x=1315199301; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=2GUlijNWdT/N/P0wUp7FmpnYtmSjE5XJM+JbuhLJPDQ=; b=HnEcobWTXlBR6gN26gR5L9722qc4zUe2J0MqrgPFZBgcIlu6IilHl1o0 ZXNqsivH1VGWBlRLzWLBttOdYShdDYOtszoh3wlCGplAWTsZpBrgcyzcK +Btq7x797X/v4e/mUWAyKNj1ZmTZO0s4q8au1pQWsUKoxK7alEf02WbE9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0GAOPjUU6rRDoG/2dsb2JhbABBmHWPHneBWQEKHYIynWuBIwGdf4VpXwSHYIs0hQyMCg X-IronPort-AV: E=Sophos;i="4.68,261,1312156800"; d="scan'208";a="15183898" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 22 Aug 2011 05:08:14 +0000 Received: from [10.33.249.7] ([10.33.249.7]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7M58DDg003798 for ; Mon, 22 Aug 2011 05:08:13 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Aug 2011 22:07:58 -0700 Message-Id: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 05:07:17 -0000 This announcement is for the working group last call of = draft-ietf-tls-dtls-heartbeat-02. Please send comments to the list by = September 09, 2011. =20 From n.mavrogiannopoulos@gmail.com Mon Aug 22 00:07:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24721F86C0 for ; Mon, 22 Aug 2011 00:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hID5HKJ+lkyq for ; Mon, 22 Aug 2011 00:07:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95E4F21F85A1 for ; Mon, 22 Aug 2011 00:07:19 -0700 (PDT) Received: by wyg8 with SMTP id 8so3867199wyg.31 for ; Mon, 22 Aug 2011 00:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=pl2iGFOp8GZgm0auv2pGGM4gTAXdxe/3AF9IbQwqvZ0=; b=K9OT/2SBhMBQh/GeQ8kMqP8yETe8/CBV1Q3MsfQ1qBJRzz5JT+BuBFBGz2Mznw1RcC ZN62mTJu/WYz3NbiznlzwLaqvCHd9gGjiZjsxhihGFfcmQMUqEloCLdsKQbHeQ4Fb5v4 8hGD0eSlFm+NbLIJ0qlu4LImfwQNzeravAOck= Received: by 10.227.32.129 with SMTP id c1mr1658571wbd.32.1313996902059; Mon, 22 Aug 2011 00:08:22 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id n20sm2183900wbh.50.2011.08.22.00.08.20 (version=SSLv3 cipher=OTHER); Mon, 22 Aug 2011 00:08:20 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E520063.7020206@gnutls.org> Date: Mon, 22 Aug 2011 09:08:19 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: tls@ietf.org References: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> In-Reply-To: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 07:07:21 -0000 On 08/22/2011 07:07 AM, Joe Salowey wrote: > This announcement is for the working group last call of > draft-ietf-tls-dtls-heartbeat-02. Please send comments to the list > by September 09, 2011. As I understand the draft this extension is 2 things: 1. A keepalive ping for TLS and DTLS 2. PMTU discovery mechanism for DTLS My unanswered comments on a previous post [0] still stand. I expand below. I believe more rationale is needed in the draft on _why_ should these issues be solved at TLS or DTLS level. For (1), TCP has a keepalive mechanism, so reintroducing it at TLS doesn't make much sense, and UDP throws the burden to user protocol. So why not throw the burden on the protocol above? The only discussion on text is: "Sending HeartbeatRequest messages allows the sender to make sure that it can reach the peer and the peer is alive. Even in case of TLS/TCP this allows this check at a much higher rate than the TCP keepalive feature would allow." So is this just a high-rate TCP keepalive? Why do we need that at the security layer? Why not propose a high-rate TCP keepalive? About (2) Both TCP and UDP don't bother with a special PMTU discovery mechanism. Why should DTLS or TLS provide it? Are there advantages on making a PMTU discovery at this level? Note that I am not opposing to the idea of providing those, if there is a good reason, but I don't see that now. regards, Nikos [0]. http://www.ietf.org/mail-archive/web/tls/current/msg07580.html From Michael.Tuexen@lurchi.franken.de Mon Aug 22 02:45:28 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B1021F85A4 for ; Mon, 22 Aug 2011 02:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBbXtE78QmoT for ; Mon, 22 Aug 2011 02:45:17 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8A52421F84D8 for ; Mon, 22 Aug 2011 02:45:16 -0700 (PDT) Received: from [192.168.1.103] (p5481B166.dip.t-dialin.net [84.129.177.102]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BE19A1C0C0BD8; Mon, 22 Aug 2011 11:46:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4E520063.7020206@gnutls.org> Date: Mon, 22 Aug 2011 11:46:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> <4E520063.7020206@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 09:45:28 -0000 On Aug 22, 2011, at 9:08 AM, Nikos Mavrogiannopoulos wrote: > On 08/22/2011 07:07 AM, Joe Salowey wrote: >> This announcement is for the working group last call of=20 >> draft-ietf-tls-dtls-heartbeat-02. Please send comments to the list=20= >> by September 09, 2011. >=20 > As I understand the draft this extension is 2 things: > 1. A keepalive ping for TLS and DTLS Correct. > 2. PMTU discovery mechanism for DTLS Incorrect. It provides a test message mechanism which can be used for path MTU discovery as described in http://tools.ietf.org/html/rfc4821 >=20 > My unanswered comments on a previous post [0] still stand. > I expand below. >=20 > I believe more rationale is needed in the draft on _why_ should > these issues be solved at TLS or DTLS level. > For (1), TCP has a keepalive mechanism, so reintroducing it at TLS > doesn't make much sense, and UDP throws the burden to user protocol. = So > why not throw the burden on the protocol above? >=20 > The only discussion on text is: > "Sending HeartbeatRequest messages allows the sender to make sure = that > it can reach the peer and the peer is alive. Even in case of = TLS/TCP > this allows this check at a much higher rate than the TCP keepalive > feature would allow." > So is this just a high-rate TCP keepalive? Why do we need that at the > security layer? Why not propose a high-rate TCP keepalive? Regarding the keepalive feature: Our main motivation is not TCP keepalives. The point is that there are application protocols running over UDP which do not have a mechanism in the app protocol to do this. This is fine when running over UDP since the lower layer does not have any state. However, when the lower layer becomes DTLS instead of UDP, there is state, and it is not a good idea to keep this state there forever. So having a way for DTLS to detect that the peer is gone, helps. >=20 >=20 > About (2) Both TCP and UDP don't bother with a special PMTU discovery > mechanism. Why should DTLS or TLS provide it? Are there advantages on > making a PMTU discovery at this level? Where else? TLS has no problem since TCP segments user messages. DTLS running over UDP can not rely on it. That is why DTLS should determine the PMTU. For doing this, it needs some messages for testing, preferable not app data which might et lost during the testing. Using the HB, you have a tool to do this without relying on ICMP message. >=20 >=20 > Note that I am not opposing to the idea of providing those, if there = is > a good reason, but I don't see that now. I don't know how you can do * path MTU discovery for DTLS/UDP with having some messages like the HB = messages. * how to detect your peer is gone in case of DTLS/UDP where the app protocol provides no mechanism (which is fine for UDP, since there = is no state).=20 If I remember correctly, IPFIX is an example for this. When having this, it makes sense to provide this also for TLS, since you = can use it to tune your liveliness check without relying on the transport = stack being changed. This might also help for keeping NAT state around... >=20 > regards, > Nikos >=20 > [0]. http://www.ietf.org/mail-archive/web/tls/current/msg07580.html As said above: the main difference is that UDP does not need any state (assuming you use non-connected UDP sockets), DTLS does. Best regards Michael > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From balfanz@google.com Mon Aug 22 10:52:04 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D421F8BC5 for ; Mon, 22 Aug 2011 10:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I+6HsTB3qN9 for ; Mon, 22 Aug 2011 10:52:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1386421F8B17 for ; Mon, 22 Aug 2011 10:52:03 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p7MHr8Wa003765 for ; Mon, 22 Aug 2011 10:53:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314035588; bh=TccDs5IiFC/qk0VJGTFuTfPNgXg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=PY4JZ+b+WcHplckqvx0ntRUdIqVRgPZzY1dzRUud5qiP6XmDDyOSLzBtVmGwvPebb Eqm7RMJfX9nSo2gs+me7Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to: content-type:x-system-of-record; b=fIzQHTEtiG1zCvV0l6eCcIHtvg1zb0cNNA9YUnLhJ662LhCcC0Yn0C7W4/hbyWxOy +5YG6DOHXOKwjt4go1FXg== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by wpaz17.hot.corp.google.com with ESMTP id p7MHr7J7006731 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 10:53:07 -0700 Received: by yib2 with SMTP id 2so3628431yib.28 for ; Mon, 22 Aug 2011 10:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; bh=gaQj7US4nfbP2UA2r+vpvzWBoZkZv7/gSRfwBoORwAo=; b=jk0G+yss/GI3xzeyyRWwiyYbR1OUELd628ikyv5DcpdiepBzD7gVwqqwOHW5ZOmNe5 8mC+2l8RIxh1LE/b+xMA== Received: by 10.91.160.39 with SMTP id m39mr2616496ago.17.1314035586909; Mon, 22 Aug 2011 10:53:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.160.39 with SMTP id m39mr2616472ago.17.1314035585841; Mon, 22 Aug 2011 10:53:05 -0700 (PDT) Received: by 10.90.56.4 with HTTP; Mon, 22 Aug 2011 10:53:05 -0700 (PDT) Date: Mon, 22 Aug 2011 10:53:05 -0700 Message-ID: From: Dirk Balfanz To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e6407cd651481b04ab1bc013 X-System-Of-Record: true Subject: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:52:04 -0000 --0016e6407cd651481b04ab1bc013 Content-Type: text/plain; charset=ISO-8859-1 Dear TLS-WG, I few weeks ago I presented a proposal for an "origin-bound certificates" TLS extension at IETF 81. It's much easier to understand what this extension is trying to accomplish when presented in a broader context of web authentication (which I tried to give in Quebec), so I put together a little web site that is supposed to do just that for those who couldn't be at the IETF meeting: http://browserauth.net (This took me a little while, hence the delay in sending out the I-D). Anyway, here is the I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit for your comments/feedback. (Again, remember to read http://browserauth.net for some context.) All feedback is welcome, of course, but if you can't think of anything to comment on, I have a couple particular questions: - in Section 2.1.1 we currently stipulate that the client include the origin of the origin-bound cert as part of the OBC X.509 extension. When we implemented this, we didn't really know what to do with that data on the server side. If the client also uses TLS-SNI, then we could imagine comparing the SNI and OBC origins in some manner on the server side, but there isn't really a vehicle to signal an error back to the client saying "your SNI and OBC origins don't match". Similarly, we could perhaps at some higher layer compare the HTTP "Host" header with the OBC origin, but then again - what do you do when they don't match? Respond with a 400 at the HTTP layer? An alternative to the current language in the I-D would be to simply mark the cert as origin-bound, but without putting the origin itself into the cert. Any thoughts? - What do you think of the privacy-enhancing power of using per-origin certs? The idea there is that different domains see different "identities" (public keys) for the same client. Of course, if two domains choose to collaborate, they can probably find a way to correlate the two identities they see for the same client. This is similar to cookies, where normally "identities" (cookies) for one domain are not revealed to another domain unless, of course, they choose to collaborate. How much privacy would we really lose if we just used one certificate for all origins? It would certainly make the design and implementation simpler. (I tend to favor per-origin certs, but I'm curious as to what other people think.) Thanks for your consideration! Dirk. --0016e6407cd651481b04ab1bc013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear TLS-WG,

I few weeks ago I presented a proposal for = an "origin-bound certificates" TLS extension at IETF 81. It's= much easier to understand what this extension is trying to accomplish when= presented in a broader context of web authentication (which I tried to giv= e in Quebec), so I put together a little web site that is supposed to do ju= st that for those who couldn't be at the IETF meeting: http://browserauth.net (This took me a little while,= hence the delay in sending out the I-D).=A0

Anyway, here is the I-D:=A0http://tools.ietf.org/html/draft-balfanz-t= ls-obc, which I submit for your comments/feedback. (Again, remember to = read http://browserauth.net for some= context.)

All feedback is welcome, of course, but if you can'= t think of anything to comment on, I have a couple particular questions:

- in Section 2.1.1 we currently stipulate that the c= lient include the origin of the origin-bound cert as part of the OBC X.509 = extension. When we implemented this, we didn't really know what to do w= ith that data on the server side. If the client also uses TLS-SNI, then we = could imagine comparing the SNI and OBC origins in some manner on the serve= r side, but there isn't really a vehicle to signal an error back to the= client saying "your SNI and OBC origins don't match". Simila= rly, we could perhaps at some higher layer compare the HTTP "Host"= ; header with the OBC origin, but then again - what do you do when they don= 't match? Respond with a 400 at the HTTP layer? An alternative to the c= urrent language in the I-D would be to simply mark the cert as origin-bound= , but without putting the origin itself into the cert. Any thoughts?

- What do you think of the privacy-enhancing power of u= sing per-origin certs? The idea there is that different domains see differe= nt "identities" (public keys) for the same client. Of course, if = two domains choose to collaborate, they can probably find a way to correlat= e the two identities they see for the same client. This is similar to cooki= es, where normally "identities" (cookies) for one domain are not = revealed to another domain unless, of course, they choose to collaborate. H= ow much privacy would we really lose if we just used one certificate for al= l origins? It would certainly make the design and implementation simpler. (= I tend to favor per-origin certs, but I'm curious as to what other peop= le think.)

Thanks for your consideration!

Dirk.

--0016e6407cd651481b04ab1bc013-- From anders.rundgren@telia.com Mon Aug 22 12:23:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693AE21F8C0F for ; Mon, 22 Aug 2011 12:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HGTmiE8dY3A for ; Mon, 22 Aug 2011 12:23:06 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4497F21F8B36 for ; Mon, 22 Aug 2011 12:23:06 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E97007C0B45; Mon, 22 Aug 2011 21:24:09 +0200 Message-ID: <4E52ACCC.20303@telia.com> Date: Mon, 22 Aug 2011 21:23:56 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: Dirk Balfanz References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:23:07 -0000 Hi Dirk, I have not yet completely understood what you are trying to do but one thing that we seen to agree on is that HTTPS CCA (Client Cert Authentication) is [more or less] useless. That's at least a start :-) I don't know if you have followed the somewhat wild discussion I started a while on this list where I asked for a "logout"? FWIW, I can attest hat banks in the EU and Asia on a *massive scale* have replaced the HTTPS-CCA with application-level CCA using home-brewed plugins. I'm a little hesitant (from a deployment point-of-view) about mucking around in the TLS layer. Wouldn't it be possible to achieve this anyway web-only functionality with more "webbish" methods? Not as clean but it would probably be easier rolling out. Anders On 2011-08-22 19:53, Dirk Balfanz wrote: > Dear TLS-WG, > > I few weeks ago I presented a proposal for an "origin-bound certificates" TLS extension at IETF 81. It's much easier to understand what this extension is trying to accomplish when presented in a > broader context of web authentication (which I tried to give in Quebec), so I put together a little web site that is supposed to do just that for those who couldn't be at the IETF meeting: > http://browserauth.net (This took me a little while, hence the delay in sending out the I-D). > > Anyway, here is the I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit for your comments/feedback. (Again, remember to read http://browserauth.net for some context.) > > All feedback is welcome, of course, but if you can't think of anything to comment on, I have a couple particular questions: > > - in Section 2.1.1 we currently stipulate that the client include the origin of the origin-bound cert as part of the OBC X.509 extension. When we implemented this, we didn't really know what to do > with that data on the server side. If the client also uses TLS-SNI, then we could imagine comparing the SNI and OBC origins in some manner on the server side, but there isn't really a vehicle to > signal an error back to the client saying "your SNI and OBC origins don't match". Similarly, we could perhaps at some higher layer compare the HTTP "Host" header with the OBC origin, but then again - > what do you do when they don't match? Respond with a 400 at the HTTP layer? An alternative to the current language in the I-D would be to simply mark the cert as origin-bound, but without putting the > origin itself into the cert. Any thoughts? > > - What do you think of the privacy-enhancing power of using per-origin certs? The idea there is that different domains see different "identities" (public keys) for the same client. Of course, if two > domains choose to collaborate, they can probably find a way to correlate the two identities they see for the same client. This is similar to cookies, where normally "identities" (cookies) for one > domain are not revealed to another domain unless, of course, they choose to collaborate. How much privacy would we really lose if we just used one certificate for all origins? It would certainly make > the design and implementation simpler. (I tend to favor per-origin certs, but I'm curious as to what other people think.) > > Thanks for your consideration! > > Dirk. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From n.mavrogiannopoulos@gmail.com Mon Aug 22 12:45:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F200D21F8C87 for ; Mon, 22 Aug 2011 12:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKd-8HLpAmDN for ; Mon, 22 Aug 2011 12:45:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0073121F8C86 for ; Mon, 22 Aug 2011 12:45:09 -0700 (PDT) Received: by wyg8 with SMTP id 8so4388951wyg.31 for ; Mon, 22 Aug 2011 12:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=TD+2y3Cvh8nkZDZQC8KG0yX7Dba1+51Jc0Qh9+uFjrQ=; b=QF4NWI3FfEF8jvqoso5SvghYnNlEhkxyU5qwEc6hNiVmAtCwfrDfkWxNQgZ3a5WY69 Qco1+/GtBQC+E9LHBXYS8JODkEKKTJ37jUEo7sHa7jEsJKjDNwMBoMTKEJ5R2fzpS2K0 f/HNQFWGEM3fQuGIt5U2GPgViD2wH96tvxvjE= Received: by 10.216.169.211 with SMTP id n61mr2428795wel.83.1314042375085; Mon, 22 Aug 2011 12:46:15 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id s49sm4166344wec.1.2011.08.22.12.46.13 (version=SSLv3 cipher=OTHER); Mon, 22 Aug 2011 12:46:14 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E52B204.2020707@gnutls.org> Date: Mon, 22 Aug 2011 21:46:12 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> <4E520063.7020206@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:45:11 -0000 On 08/22/2011 11:46 AM, Michael Tüxen wrote: >> I believe more rationale is needed in the draft on _why_ should >> these issues be solved at TLS or DTLS level. For (1), TCP has a >> keepalive mechanism, so reintroducing it at TLS doesn't make much >> sense, and UDP throws the burden to user protocol. So why not throw >> the burden on the protocol above? >> The only discussion on text is: "Sending HeartbeatRequest messages >> allows the sender to make sure that it can reach the peer and the >> peer is alive. Even in case of TLS/TCP this allows this check at a >> much higher rate than the TCP keepalive feature would allow." So is >> this just a high-rate TCP keepalive? Why do we need that at the >> security layer? Why not propose a high-rate TCP keepalive? > Regarding the keepalive feature: Our main motivation is not TCP > keepalives. The point is that there are application protocols running > over UDP which do not have a Why not restrict the scope of this extension to DTLS then? (unless I'm missing some other application of this in TLS). > mechanism in the app protocol to do this. This is fine when running > over UDP since the lower layer does not have any state. However, when > the lower layer becomes DTLS instead of UDP, there is state, and it > is not a good idea to keep this state there forever. So having a way > for DTLS to detect that the peer is gone, helps. Ok, now I understand what you try to address with this extension (and it might be better for the draft text to express it as well). However is this the right solution for the problem? This does not make DTLS stateless, thus it is different in operation as the previous UDP server. Anyway you'll have to trigger the keepalive messages manually (with input from the application layer) or after some fixed time. Wouldn't this be equivalent (in resources and behavior) with trying to resume the DTLS connection after a fixed amount of time? (the handshake resumption is 3 messages, this is one message more than the 2 keep-alive messages). >> About (2) Both TCP and UDP don't bother with a special PMTU >> discovery mechanism. Why should DTLS or TLS provide it? Are there >> advantages on making a PMTU discovery at this level? > Where else? TLS has no problem since TCP segments user messages. > DTLS running over UDP can not rely on it. That is why DTLS should > determine the PMTU. For doing this, it needs some messages for > testing, preferable not app data which might et lost during the > testing. Using the HB, you have a tool to do this without relying on > ICMP message. Just from curiosity how has this been implemented in a library (or how you think of being implemented)? How did the keep-alive messages are being exchanged without the application noticing? Nits: section 3: > "it has to be answered with a corresponding HeartbeatResponse > message immediately." I don't think the immediately adds to the sentence. It just adds confusion. What if it was sending an application data packet on a different thread? Should I stop? > "HeartbeatRequest messages from older epochs SHOULD be discarded." Why HeartbeatRequest messages are treated differently? Aren't all messages with older epochs to be discarded? 5.2: "HeartbeatRequest messages SHOULD only be sent after an idle period that is at least multiple round trip times long." This is more than unclear. Why not specify how many? What if I decide 2 times and another implementor discards my message because for him multiple was > 3? regards, Nikos From Michael.Tuexen@lurchi.franken.de Tue Aug 23 02:41:00 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1821F854F for ; Tue, 23 Aug 2011 02:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+s8tlN3XqgA for ; Tue, 23 Aug 2011 02:40:59 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id AB6FB21F84DB for ; Tue, 23 Aug 2011 02:40:58 -0700 (PDT) Received: from [192.168.1.104] (p5481D90F.dip.t-dialin.net [84.129.217.15]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B0B551C0C0BD8; Tue, 23 Aug 2011 11:42:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4E52B204.2020707@gnutls.org> Date: Tue, 23 Aug 2011 11:42:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08B3F781-C6F4-46AA-9D0A-4D66D4DE6794@lurchi.franken.de> References: <67629EB8-CDF5-47B3-BC6E-C1A76E08C294@cisco.com> <4E520063.7020206@gnutls.org> <4E52B204.2020707@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] Working group last call for draft-ietf-tls-dtls-heartbeat-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 23 Aug 2011 09:41:00 -0000 On Aug 22, 2011, at 9:46 PM, Nikos Mavrogiannopoulos wrote: > On 08/22/2011 11:46 AM, Michael T=FCxen wrote: >=20 >>> I believe more rationale is needed in the draft on _why_ should=20 >>> these issues be solved at TLS or DTLS level. For (1), TCP has a >>> keepalive mechanism, so reintroducing it at TLS doesn't make much >>> sense, and UDP throws the burden to user protocol. So why not throw >>> the burden on the protocol above? >>> The only discussion on text is: "Sending HeartbeatRequest messages >>> allows the sender to make sure that it can reach the peer and the >>> peer is alive. Even in case of TLS/TCP this allows this check at a >>> much higher rate than the TCP keepalive feature would allow." So is >>> this just a high-rate TCP keepalive? Why do we need that at the=20 >>> security layer? Why not propose a high-rate TCP keepalive? >> Regarding the keepalive feature: Our main motivation is not TCP >> keepalives. The point is that there are application protocols running >> over UDP which do not have a >=20 > Why not restrict the scope of this extension to DTLS then? (unless I'm > missing some other application of this in TLS). The original ID was only limited to DTLS. But it turns out that you need nothing specific for TLS. Therefore it was suggested to make it also available on TLS. So you can check if your peer is there without relying on TCP keep = alive. Or refresh the NAT state. Up to the app writer. >=20 >> mechanism in the app protocol to do this. This is fine when running=20= >> over UDP since the lower layer does not have any state. However, when >> the lower layer becomes DTLS instead of UDP, there is state, and it >> is not a good idea to keep this state there forever. So having a way >> for DTLS to detect that the peer is gone, helps. >=20 > Ok, now I understand what you try to address with this extension (and = it > might be better for the draft text to express it as well). However is Any suggested text? > this the right solution for the problem? This does not make DTLS > stateless, thus it is different in operation as the previous UDP = server. > Anyway you'll have to trigger the keepalive messages manually (with > input from the application layer) or after some fixed time. >=20 > Wouldn't this be equivalent (in resources and behavior) with trying > to resume the DTLS connection after a fixed amount of time? > (the handshake resumption is 3 messages, this is one message more than > the 2 keep-alive messages). This was used by the IPFix guys as a workaround. Just sending a message which gets reflected is much simpler. It might also be a problem sending data while doing session resumption. (the node issuing the session resumption might not be the data = sender...) >=20 >>> About (2) Both TCP and UDP don't bother with a special PMTU >>> discovery mechanism. Why should DTLS or TLS provide it? Are there >>> advantages on making a PMTU discovery at this level? >> Where else? TLS has no problem since TCP segments user messages. >> DTLS running over UDP can not rely on it. That is why DTLS should >> determine the PMTU. For doing this, it needs some messages for >> testing, preferable not app data which might et lost during the >> testing. Using the HB, you have a tool to do this without relying on >> ICMP message. >=20 > Just from curiosity how has this been implemented in a library (or how > you think of being implemented)? How did the keep-alive messages are > being exchanged without the application noticing? The application can call a function which sends a HB. If there is a response, the app will not get anything. If there is no response, the app will et notified that the DTLS session is gone... We have a patch for OpenSSL available at http://sctp.fh-muenster.de/dtls-patches.html The retransmissions are handled by the DTLS implementation. >=20 >=20 > Nits: > section 3: >> "it has to be answered with a corresponding HeartbeatResponse >> message > immediately." > I don't think the immediately adds to the sentence. It just adds > confusion. What if it was sending an application data packet on a > different thread? Should I stop? No. I just wanted to make clear that you should not start a timer or something like that. We can take out "immediately". >=20 >=20 >> "HeartbeatRequest messages from older epochs SHOULD be discarded." > Why HeartbeatRequest messages are treated differently? Aren't all > messages with older epochs to be discarded? No.=20 http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-06 contains: Note that because DTLS records may be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP [TCP] to allow for packet reordering. (Note: the intention here is that implementors use the current guidance from the IETF for MSL, not that they attempt to interrogate the MSL the system TCP stack is using.) Until the handshake has completed, implementations MUST accept packets from the old epoch. >=20 > 5.2: > "HeartbeatRequest messages SHOULD only be sent after an idle period > that is at least multiple round trip times long." > This is more than unclear. Why not specify how many? What if I decide = 2 > times and another implementor discards my message because for him > multiple was > 3? That text was suggested by the TSV directorate... It is up to the application writer what he wants to do. The longer he waits, the longer it takes to detect that the peer is gone. For congestion control the only thing which is important is that you do send a not more than one HB per RTT. This is enforced by the implementation with not having more than one outstanding HB. Best regards Michael >=20 >=20 > regards, > Nikos >=20 >=20 >=20 >=20 From chris@randomnonce.org Tue Aug 23 16:24:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB421F8C75 for ; Tue, 23 Aug 2011 16:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pJssKcxo3Q2 for ; Tue, 23 Aug 2011 16:24:20 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E105A21F8C66 for ; Tue, 23 Aug 2011 16:24:19 -0700 (PDT) Received: by qyk34 with SMTP id 34so2349785qyk.10 for ; Tue, 23 Aug 2011 16:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.90.71 with SMTP id h7mr2735126qcm.295.1314141926292; Tue, 23 Aug 2011 16:25:26 -0700 (PDT) Received: by 10.229.237.144 with HTTP; Tue, 23 Aug 2011 16:25:26 -0700 (PDT) X-Originating-IP: [207.145.38.73] In-Reply-To: References: Date: Tue, 23 Aug 2011 19:25:26 -0400 Message-ID: From: Chris Richardson To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 23 Aug 2011 23:24:20 -0000 I think the draft is inconsistent with respect to=A0the certificate_authorities list. >From section 3.3: "[if both sides include the extension], client and server are considered to have negotiated origin-bound client certificates for the session." No problem there. >From section 3.4: "the server MAY use an empty "certificate_authorities" li= st" Should that be a MUST, or at least a SHOULD? If OBC has been negotiated, why would a CA-signed cert be used? >From section 3.4: [the client] MUST ignore the "certificate_authorities" li= st No problem there, but it again makes me think the server SHOULD/MUST send an empty list. Section 3.5: If the "certificate_authorities" list in the Certificate Request is empty, that certificate SHOULD be an origin-bound certificate, and it should be selected by the client without any assistance or approval by the end-user. If the "certificate_authorities" list in the Certificate Request is not empty, the client MAY select a regular certificate for inclusion in the Client Certificate message, and MAY involve the end-user in the certificate selection process." The client MUST ignore the list, but MAY take action based upon the content of the list? Chris On Mon, Aug 22, 2011 at 1:53 PM, Dirk Balfanz wrote: > > Dear TLS-WG, > I few weeks ago I presented a proposal for an "origin-bound certificates"= TLS extension at IETF 81. It's much easier to understand what this extensi= on is trying to accomplish when presented in a broader context of web authe= ntication (which I tried to give in Quebec), so I put together a little web= site that is supposed to do just that for those who couldn't be at the IET= F meeting: http://browserauth.net (This took me a little while, hence the d= elay in sending out the I-D). > Anyway, here is the I-D:=A0http://tools.ietf.org/html/draft-balfanz-tls-o= bc, which I submit for your comments/feedback. (Again, remember to read htt= p://browserauth.net for some context.) > All feedback is welcome, of course, but if you can't think of anything to= comment on, I have a couple particular questions: > - in Section 2.1.1 we currently stipulate that the client include the ori= gin of the origin-bound cert as part of the OBC X.509 extension. When we im= plemented this, we didn't really know what to do with that data on the serv= er side. If the client also uses TLS-SNI, then we could imagine comparing t= he SNI and OBC origins in some manner on the server side, but there isn't r= eally a vehicle to signal an error back to the client saying "your SNI and = OBC origins don't match". Similarly, we could perhaps at some higher layer = compare the HTTP "Host" header with the OBC origin, but then again - what d= o you do when they don't match? Respond with a 400 at the HTTP layer? An al= ternative to the current language in the I-D would be to simply mark the ce= rt as origin-bound, but without putting the origin itself into the cert. An= y thoughts? > - What do you think of the privacy-enhancing power of using per-origin ce= rts? The idea there is that different domains see different "identities" (p= ublic keys) for the same client. Of course, if two domains choose to collab= orate, they can probably find a way to correlate the two identities they se= e for the same client. This is similar to cookies, where normally "identiti= es" (cookies) for one domain are not revealed to another domain unless, of = course, they choose to collaborate. How much privacy would we really lose i= f we just used one certificate for all origins? It would certainly make the= design and implementation simpler. (I tend to favor per-origin certs, but = I'm curious as to what other people think.) > Thanks for your consideration! > Dirk. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From wtc@google.com Tue Aug 23 16:38:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165B621F8BB2 for ; Tue, 23 Aug 2011 16:38:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77yFRCk2xmBV for ; Tue, 23 Aug 2011 16:38:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9121F8B98 for ; Tue, 23 Aug 2011 16:38:17 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p7NNdLxv005103 for ; Tue, 23 Aug 2011 16:39:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314142761; bh=UJeNsxOMJx5IMUCKhb9uhdzIHKs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=e/v2uJbQ6lCuY9qKJ7lq1fihhhIP6X1ruWZ3Ck8/ZujatQ/r0tH5TpwwoNrQdTT/q ZuU+IM4GIT1LN3rIFB2TA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=KrLU+azKP0cEaVPB2MJ4owzGv427wG6tvQuXpaI1cJKgSYbxoA0RV9uDdOxAgxzDi ibxLui8jktHN4cylZCAbw== Received: from qyk31 (qyk31.prod.google.com [10.241.83.159]) by hpaq12.eem.corp.google.com with ESMTP id p7NNdJRF002188 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 23 Aug 2011 16:39:20 -0700 Received: by qyk31 with SMTP id 31so3334532qyk.18 for ; Tue, 23 Aug 2011 16:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B6MzXkS989/M46Vj+5lEIfJXDzkL4BhgvzqiHalsX3k=; b=nvNooHQ8hLowLhXXgnAjLbdzcvKsD0NFP6T2/wBdQIFAdojGO4I+CzH55fJM5+zcqO VLDzo+NHAiOxwNqKD0+g== Received: by 10.229.33.71 with SMTP id g7mr2882400qcd.26.1314142759166; Tue, 23 Aug 2011 16:39:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.33.71 with SMTP id g7mr2882393qcd.26.1314142759002; Tue, 23 Aug 2011 16:39:19 -0700 (PDT) Received: by 10.229.102.159 with HTTP; Tue, 23 Aug 2011 16:39:18 -0700 (PDT) In-Reply-To: <4E52ACCC.20303@telia.com> References: <4E52ACCC.20303@telia.com> Date: Tue, 23 Aug 2011 16:39:18 -0700 Message-ID: From: Wan-Teh Chang To: Anders Rundgren Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 23 Aug 2011 23:38:19 -0000 On Mon, Aug 22, 2011 at 12:23 PM, Anders Rundgren wrote: > > I'm a little hesitant (from a deployment point-of-view) about mucking > around in the TLS layer. =A0Wouldn't it be possible to achieve this > anyway web-only functionality with more "webbish" methods? =A0Not as > clean but it would probably be easier rolling out. The reason the origin-bound certificates are used in TLS client authentication is to save one round trip. Otherwise the server will need to send a challenge for the client to sign. There is a variant where the client signs a shared value derived from the TLS master secret, to avoid the need for the server to send a challenge. That variant can be used at the HTTP layer when running over TLS. Wan-Teh From chris.newman@oracle.com Wed Aug 24 10:39:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6402821F8BF9 for ; Wed, 24 Aug 2011 10:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.432 X-Spam-Level: X-Spam-Status: No, score=-105.432 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtICTe0w8LgB for ; Wed, 24 Aug 2011 10:39:45 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by ietfa.amsl.com (Postfix) with ESMTP id A7F7A21F8B54 for ; Wed, 24 Aug 2011 10:39:45 -0700 (PDT) Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7OHerSj020977; Wed, 24 Aug 2011 17:40:53 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7OHeqOl012734; Wed, 24 Aug 2011 17:40:53 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQG00028141TS00@gotmail.us.oracle.com>; Wed, 24 Aug 2011 10:40:53 -0700 (PDT) Date: Tue, 23 Aug 2011 21:58:10 -0700 From: Chris Newman To: Dirk Balfanz , tls@ietf.org Message-id: <7BAD42FE4F789E2903A528D5@nifty-silver.local> In-reply-to: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:39:46 -0000 TLS client certificate authentication is used sometimes with email. Indeed it's a significant reason this draft is needed: draft-melnikov-pop3-over-tls-01.txt. Some mail clients associate a single TLS client certificate with a "mail account" and would not benefit from OBC. Some mail clients store TLS client certificates in a pool and one has to be selected for a given account when the server requests a client certificate. Such mail clients would benefit from OBC. However, the two most widely deployed open source TLS stacks (OpenSSL & NSS) are changing very slowly. I'm skeptical that OBC provides enough benefit to actually get implemented and deployed in such TLS stacks. Do you know of implementers sufficiently interested in the feature that they would be willing to contribute code to OpenSSL and NSS? - Chris --On August 22, 2011 10:53:05 -0700 Dirk Balfanz wrote: > Dear TLS-WG, > > I few weeks ago I presented a proposal for an "origin-bound certificates" > TLS extension at IETF 81. It's much easier to understand what this > extension is trying to accomplish when presented in a broader context of > web authentication (which I tried to give in Quebec), so I put together a > little web site that is supposed to do just that for those who couldn't > be at the IETF meeting: http://browserauth.net (This took me a little > while, hence the delay in sending out the I-D). > > Anyway, here is the I-D: http://tools.ietf.org/html/draft-balfanz-tls-obc, > which I submit for your comments/feedback. (Again, remember to read > http://browserauth.net for some context.) > > All feedback is welcome, of course, but if you can't think of anything to > comment on, I have a couple particular questions: > > - in Section 2.1.1 we currently stipulate that the client include the > origin of the origin-bound cert as part of the OBC X.509 extension. When > we implemented this, we didn't really know what to do with that data on > the server side. If the client also uses TLS-SNI, then we could imagine > comparing the SNI and OBC origins in some manner on the server side, but > there isn't really a vehicle to signal an error back to the client saying > "your SNI and OBC origins don't match". Similarly, we could perhaps at > some higher layer compare the HTTP "Host" header with the OBC origin, but > then again - what do you do when they don't match? Respond with a 400 at > the HTTP layer? An alternative to the current language in the I-D would > be to simply mark the cert as origin-bound, but without putting the > origin itself into the cert. Any thoughts? > > - What do you think of the privacy-enhancing power of using per-origin > certs? The idea there is that different domains see different "identities" > (public keys) for the same client. Of course, if two domains choose to > collaborate, they can probably find a way to correlate the two identities > they see for the same client. This is similar to cookies, where normally > "identities" (cookies) for one domain are not revealed to another domain > unless, of course, they choose to collaborate. How much privacy would we > really lose if we just used one certificate for all origins? It would > certainly make the design and implementation simpler. (I tend to favor > per-origin certs, but I'm curious as to what other people think.) > > Thanks for your consideration! > > Dirk. > From balfanz@google.com Wed Aug 24 23:01:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2366721F8A69 for ; Wed, 24 Aug 2011 23:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok6zwZhSgW6y for ; Wed, 24 Aug 2011 23:01:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8602A21F8A91 for ; Wed, 24 Aug 2011 23:01:29 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p7P62fkV004253 for ; Wed, 24 Aug 2011 23:02:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314252161; bh=n7ogM1KHdHqAw8IbDbqpEuyxEQo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YW44eNrg71WuyTGrT1HZfw23n333mio8Ti0AcqXWpRVvtZLTaGiwU00XDi1IiLfue MFVeyWzamVLAzamd6F7rQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=PDu/gCnI2wVu+GhDyPSFkVonBaVrehaomdKp0v8A43flpbmnv8CxnD/OrR1UCHjtm Xc3rkhh02EAhPRTlq3mRg== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by hpaq3.eem.corp.google.com with ESMTP id p7P627vM006943 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 24 Aug 2011 23:02:40 -0700 Received: by gyg4 with SMTP id 4so1842122gyg.34 for ; Wed, 24 Aug 2011 23:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sv9+BNbqTSbh8r+oxapxaSAhuIOtWQmBsPRr9j1jE3k=; b=xWSKtGxB040vaqtevagMUkgDR2QU6ZXgUwD2ofS59eR9wkFBkJX99OOWa55UHLctbX ZnBJSXsrVbCDT9D5EoRg== Received: by 10.91.3.3 with SMTP id f3mr5823526agi.71.1314252159601; Wed, 24 Aug 2011 23:02:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.3.3 with SMTP id f3mr5823516agi.71.1314252159224; Wed, 24 Aug 2011 23:02:39 -0700 (PDT) Received: by 10.90.56.4 with HTTP; Wed, 24 Aug 2011 23:02:39 -0700 (PDT) In-Reply-To: <4E52ACCC.20303@telia.com> References: <4E52ACCC.20303@telia.com> Date: Wed, 24 Aug 2011 23:02:39 -0700 Message-ID: From: Dirk Balfanz To: Anders Rundgren Content-Type: multipart/alternative; boundary=0016363b8084188a9804ab4e2df8 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 06:01:31 -0000 --0016363b8084188a9804ab4e2df8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 22, 2011 at 12:23 PM, Anders Rundgren wrote: > Hi Dirk, > > I have not yet completely understood what you are trying to do but one > thing that we seen to agree on is that HTTPS CCA (Client Cert > Authentication) > is [more or less] useless. That's at least a start :-) > > I don't know if you have followed the somewhat wild discussion I started > a while on this list where I asked for a "logout"? > No sorry I missed those! But speaking of logout - with TLS-OBC and channel-bound cookies, logout is easy: you do it just like you do it today: by overriding or expiring the cookie you set when you "logged in" the user. > > FWIW, I can attest hat banks in the EU and Asia on a *massive scale* have > replaced the HTTPS-CCA with application-level CCA using home-brewed > plugins. > > I'm a little hesitant (from a deployment point-of-view) about mucking > around in the TLS layer. Wouldn't it be possible to achieve this > anyway web-only functionality with more "webbish" methods? Not as > clean but it would probably be easier rolling out. > I made a few attempts at doing this on the application and HTTP layers - they didn't really work out. One problem is security: if we look at integrity, for example, TLS gives us that for free. To recreate that, say, at the HTTP layer, we'd have to invent some form of signature on the HTTP request. So immediately the question is: how much of the request do you sign? Do you sign the all headers? The POST body? If you sign the whole POST body, then you can't generate the signature until you've seen the whole POST body. What if the POST body is a multi-gigabyte video? And if the signature goes into the HTTP headers, which must come _before_ the POST body, this means you have read the whole POST body for signing it, and then read it again to pump it out to the network (assuming it's so big that it doesn't fit into whatever buffer you have). Another problem was performance: Signing every single HTTP request with an asymmetric key seems like overkill. So somehow, the server and client would have to negotiate an HMAC key that would be used to sign HTTP requests. That HMAC key would probably be visible to the attacker (which we assume sits in the browser). To decrease the benefit that the attacker has from seeing the HMAC key, we would re-negotiate a new HMAC key every so often, with the client having to re-prove that it is in possession of its private key (we assume that the attacker can't get to the private key, since that can sit in a TPM). It's hard to imagine how to do that on the HTTP or application layer without introducing a roundtrip between client and server that establishes that new HMAC key. While that roundtrip is happening, you can't make other calls to the server (well, you can make 3 others or so depending on how many simultaneous HTTP connections your browser allows with a server, but the point is that you're using one of your limited number of TCP channels for this key renegotiation). In TLS, we have a similar problem - the session master secret might be known to the attacker, so every now and then we'd like to reset it by renegotiating the TLS session. In TLS, however, we can interleave data and handshake messages, so renegotiating the session secret doesn't mean that we're holding up a whole TCP connection. These (and a couple of other) nice features that TLS gives us for free we would end up "reinventing" on the HTTP or application layers, up to the point where we would have reinvented almost all of TLS. Dirk. P.S. I should also mention that doing this on the application layer (i.e., TLS doesn't know about this, HTTP doesn't know about this, but the client-side and server-side libraries we use to write our apps would provide the necessary functionality) also would have meant that apps would have to be substantially re-written, which we thought was a show-stopper. So the only serious contender was to do this at the HTTP layer. > Anders > > On 2011-08-22 19:53, Dirk Balfanz wrote: > > Dear TLS-WG, > > > > I few weeks ago I presented a proposal for an "origin-bound certificates" > TLS extension at IETF 81. It's much easier to understand what this extension > is trying to accomplish when presented in a > > broader context of web authentication (which I tried to give in Quebec), > so I put together a little web site that is supposed to do just that for > those who couldn't be at the IETF meeting: > > http://browserauth.net (This took me a little while, hence the delay in > sending out the I-D). > > > > Anyway, here is the I-D: > http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit for your > comments/feedback. (Again, remember to read http://browserauth.net for > some context.) > > > > All feedback is welcome, of course, but if you can't think of anything to > comment on, I have a couple particular questions: > > > > - in Section 2.1.1 we currently stipulate that the client include the > origin of the origin-bound cert as part of the OBC X.509 extension. When we > implemented this, we didn't really know what to do > > with that data on the server side. If the client also uses TLS-SNI, then > we could imagine comparing the SNI and OBC origins in some manner on the > server side, but there isn't really a vehicle to > > signal an error back to the client saying "your SNI and OBC origins don't > match". Similarly, we could perhaps at some higher layer compare the HTTP > "Host" header with the OBC origin, but then again - > > what do you do when they don't match? Respond with a 400 at the HTTP > layer? An alternative to the current language in the I-D would be to simply > mark the cert as origin-bound, but without putting the > > origin itself into the cert. Any thoughts? > > > > - What do you think of the privacy-enhancing power of using per-origin > certs? The idea there is that different domains see different "identities" > (public keys) for the same client. Of course, if two > > domains choose to collaborate, they can probably find a way to correlate > the two identities they see for the same client. This is similar to cookies, > where normally "identities" (cookies) for one > > domain are not revealed to another domain unless, of course, they choose > to collaborate. How much privacy would we really lose if we just used one > certificate for all origins? It would certainly make > > the design and implementation simpler. (I tend to favor per-origin certs, > but I'm curious as to what other people think.) > > > > Thanks for your consideration! > > > > Dirk. > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > --0016363b8084188a9804ab4e2df8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 12:23 PM, Anders Rundgren <anders.rundgren@telia.com>= wrote:

FWIW, I can attest hat banks in the EU and Asia on a *massive scale* have replaced the HTTPS-CCA with application-level CCA using home-brewed plugins= .

I'm a little hesitant (from a deployment point-of-view) about mucking around in the TLS layer. =A0Wouldn't it be possible to achieve this
anyway web-only functionality with more "webbish" methods? =A0Not= as
clean but it would probably be easier rolling out.
I made a few attempts at doing this on the application and HTTP= layers - they didn't really work out. One problem is security: if we l= ook at integrity, for example, TLS gives us that for free. To recreate that= , say, at the HTTP layer, we'd have to invent some form of signature on= the HTTP request. So immediately the question is: how much of the request = do you sign? Do you sign the all headers? The POST body? If you sign the wh= ole POST body, then you can't generate the signature until you've s= een the whole POST body. What if the POST body is a multi-gigabyte video? A= nd if the signature goes into the HTTP headers, which must come _before_ th= e POST body, this means you have read the whole POST body for signing it, a= nd then read it again to pump it out to the network (assuming it's so b= ig that it doesn't fit into whatever buffer you have).=A0

Another problem was performance: Signing every single H= TTP request with an asymmetric key seems like overkill. So somehow, the ser= ver and client would have to negotiate an HMAC key that would be used to si= gn HTTP requests. That HMAC key would probably be visible to the attacker (= which we assume sits in the browser). To decrease the benefit that the atta= cker has from seeing the HMAC key, we would re-negotiate a new HMAC key eve= ry so often, with the client having to re-prove that it is in possession of= its private key (we assume that the attacker can't get to the private = key, since that can sit in a TPM). It's hard to imagine how to do that = on the HTTP or application layer without introducing a roundtrip between cl= ient and server that establishes that new HMAC key. While that roundtrip is= happening, you can't make other calls to the server (well, you can mak= e 3 others or so depending on how many simultaneous HTTP connections your b= rowser allows with a server, but the point is that you're using one of = your limited number of TCP channels for this key renegotiation). In TLS, we= have a similar problem - the session master secret might be known to the a= ttacker, so every now and then we'd like to reset it by renegotiating t= he TLS session. In TLS, however, we can interleave data and handshake messa= ges, so renegotiating the session secret doesn't mean that we're ho= lding up a whole TCP connection.=A0

These (and a couple of other) nice features that TLS gi= ves us for free we would end up "reinventing" on the HTTP or appl= ication layers, up to the point where we would have reinvented almost all o= f TLS.

Dirk.=A0

P.S. I should also me= ntion that doing this on the application layer (i.e., TLS doesn't know = about this, HTTP doesn't know about this, but the client-side and serve= r-side libraries we use to write our apps would provide the necessary funct= ionality) also would have meant that apps would have to be substantially re= -written, which we thought was a show-stopper. So the only serious contende= r was to do this at the HTTP layer.



Anders

On 2011-08-22 19:53, Dirk Balfanz wrote:
> Dear TLS-WG,
>
> I few weeks ago I presented a proposal for an "origin-bound certi= ficates" TLS extension at IETF 81. It's much easier to understand = what this extension is trying to accomplish when presented in a
> broader context of web authentication (which I tried to give in Quebec= ), so I put together a little web site that is supposed to do just that for= those who couldn't be at the IETF meeting:
> http://browseraut= h.net (This took me a little while, hence the delay in sending out the = I-D).
>
> Anyway, here is the I-D: http://tools.ietf.org/html/draft-balfanz-= tls-obc, which I submit for your comments/feedback. (Again, remember to= read http://browserau= th.net for some context.)
>
> All feedback is welcome, of course, but if you can't think of anyt= hing to comment on, I have a couple particular questions:
>
> - in Section 2.1.1 we currently stipulate that the client include the = origin of the origin-bound cert as part of the OBC X.509 extension. When we= implemented this, we didn't really know what to do
> with that data on the server side. If the client also uses TLS-SNI, th= en we could imagine comparing the SNI and OBC origins in some manner on the= server side, but there isn't really a vehicle to
> signal an error back to the client saying "your SNI and OBC origi= ns don't match". Similarly, we could perhaps at some higher layer = compare the HTTP "Host" header with the OBC origin, but then agai= n -
> what do you do when they don't match? Respond with a 400 at the HT= TP layer? An alternative to the current language in the I-D would be to sim= ply mark the cert as origin-bound, but without putting the
> origin itself into the cert. Any thoughts?
>
> - What do you think of the privacy-enhancing power of using per-origin= certs? The idea there is that different domains see different "identi= ties" (public keys) for the same client. Of course, if two
> domains choose to collaborate, they can probably find a way to correla= te the two identities they see for the same client. This is similar to cook= ies, where normally "identities" (cookies) for one
> domain are not revealed to another domain unless, of course, they choo= se to collaborate. How much privacy would we really lose if we just used on= e certificate for all origins? It would certainly make
> the design and implementation simpler. (I tend to favor per-origin cer= ts, but I'm curious as to what other people think.)
>
> Thanks for your consideration!
>
> Dirk.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--0016363b8084188a9804ab4e2df8-- From balfanz@google.com Wed Aug 24 23:21:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8B021F875E for ; Wed, 24 Aug 2011 23:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.559 X-Spam-Level: X-Spam-Status: No, score=-105.559 tagged_above=-999 required=5 tests=[AWL=0.417, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcjva9JmnCgJ for ; Wed, 24 Aug 2011 23:21:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8921F8754 for ; Wed, 24 Aug 2011 23:21:16 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p7P6MSDf006594 for ; Wed, 24 Aug 2011 23:22:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314253348; bh=xST4Kwjz6NgvMdLgOJPPpp9dOp0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XK0Ezd7C76LV4DFudWCuH9K8m8BwyHnTIYn2sZ8p/xSbUfK+DoLj4mzm2iapeCNk3 Jc1JCwsKMk8sjq0eWqkRg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=LLJyHnHap7MvS6VXnCDTxZY2Tnn9SZesqX6zXst48zEeI6izywxoN7kgRSrMQjRc+ Y4fhHdAqa3AhpMQXI7z6g== Received: from gwj17 (gwj17.prod.google.com [10.200.10.17]) by hpaq1.eem.corp.google.com with ESMTP id p7P6MQYG009774 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 24 Aug 2011 23:22:27 -0700 Received: by gwj17 with SMTP id 17so1314135gwj.10 for ; Wed, 24 Aug 2011 23:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h9UzrzSYtPSNb2FIQtY19zOMToWHh2QAAYOJYkd+Svs=; b=eINqFG4KZ/Nd5ah9GmmwfHMtCiaFyl0pF3PnfuGalP18v1kBxiUM7aOcaLI3+L96bc UO9pPcKVWzSnwWnA/H6A== Received: by 10.91.160.39 with SMTP id m39mr5859054ago.17.1314253345811; Wed, 24 Aug 2011 23:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.160.39 with SMTP id m39mr5859044ago.17.1314253345524; Wed, 24 Aug 2011 23:22:25 -0700 (PDT) Received: by 10.90.56.4 with HTTP; Wed, 24 Aug 2011 23:22:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 23:22:25 -0700 Message-ID: From: Dirk Balfanz To: Chris Richardson Content-Type: multipart/alternative; boundary=0016e6407cd6cec15e04ab4e731e X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 06:21:18 -0000 --0016e6407cd6cec15e04ab4e731e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 23, 2011 at 4:25 PM, Chris Richardson wrote: > I think the draft is inconsistent with respect to the > certificate_authorities list. > > From section 3.3: "[if both sides include the extension], client and > server are considered to have negotiated origin-bound client > certificates for the session." > > No problem there. > > From section 3.4: "the server MAY use an empty "certificate_authorities" > list" > > Should that be a MUST, or at least a SHOULD? If OBC has been > negotiated, why would a CA-signed cert be used? > Agreed. I'll fix it. Probably a SHOULD, just in case some servers find it hard to turn off their standard list of CAs? > > From section 3.4: [the client] MUST ignore the "certificate_authorities" > list > > No problem there, but it again makes me think the server SHOULD/MUST > send an empty list. > > Section 3.5: If the "certificate_authorities" list in the Certificate > Request is empty, that certificate SHOULD be an origin-bound > certificate, and it should be selected by the client without any > assistance or approval by the end-user. If the > "certificate_authorities" list in the Certificate Request is not > empty, the client MAY select a regular certificate for inclusion in > the Client Certificate message, and MAY involve the end-user in the > certificate selection process." > > The client MUST ignore the list, but MAY take action based upon the > content of the list? > Good catch - you're seeing a bad merge of two different versions of this section. The one I meant to be in there is the one where the client MUST ignore the list (long story...:-). I'll collect more comments for now (instead of fixing it right away), but I will make sure that gets fixed in the next draft. Dirk. > > Chris > > > On Mon, Aug 22, 2011 at 1:53 PM, Dirk Balfanz wrote: > > > > Dear TLS-WG, > > I few weeks ago I presented a proposal for an "origin-bound certificates" > TLS extension at IETF 81. It's much easier to understand what this extension > is trying to accomplish when presented in a broader context of web > authentication (which I tried to give in Quebec), so I put together a little > web site that is supposed to do just that for those who couldn't be at the > IETF meeting: http://browserauth.net (This took me a little while, hence > the delay in sending out the I-D). > > Anyway, here is the I-D: > http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit for your > comments/feedback. (Again, remember to read http://browserauth.net for > some context.) > > All feedback is welcome, of course, but if you can't think of anything to > comment on, I have a couple particular questions: > > - in Section 2.1.1 we currently stipulate that the client include the > origin of the origin-bound cert as part of the OBC X.509 extension. When we > implemented this, we didn't really know what to do with that data on the > server side. If the client also uses TLS-SNI, then we could imagine > comparing the SNI and OBC origins in some manner on the server side, but > there isn't really a vehicle to signal an error back to the client saying > "your SNI and OBC origins don't match". Similarly, we could perhaps at some > higher layer compare the HTTP "Host" header with the OBC origin, but then > again - what do you do when they don't match? Respond with a 400 at the HTTP > layer? An alternative to the current language in the I-D would be to simply > mark the cert as origin-bound, but without putting the origin itself into > the cert. Any thoughts? > > - What do you think of the privacy-enhancing power of using per-origin > certs? The idea there is that different domains see different "identities" > (public keys) for the same client. Of course, if two domains choose to > collaborate, they can probably find a way to correlate the two identities > they see for the same client. This is similar to cookies, where normally > "identities" (cookies) for one domain are not revealed to another domain > unless, of course, they choose to collaborate. How much privacy would we > really lose if we just used one certificate for all origins? It would > certainly make the design and implementation simpler. (I tend to favor > per-origin certs, but I'm curious as to what other people think.) > > Thanks for your consideration! > > Dirk. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --0016e6407cd6cec15e04ab4e731e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 23, 2011 at 4:25 PM, Chris R= ichardson <ch= ris@randomnonce.org> wrote:

>From section 3.4: [the client] MUST ignore the "certificate_authoritie= s" list

No problem there, but it again makes me think the server SHOULD/MUST
send an empty list.

Section 3.5: If the "certificate_authorities" list in the Certifi= cate
Request is empty, that certificate SHOULD be an origin-bound
certificate, and it should be selected by the client without any
assistance or approval by the end-user. If the
"certificate_authorities" list in the Certificate Request is not<= br> empty, the client MAY select a regular certificate for inclusion in
the Client Certificate message, and MAY involve the end-user in the
certificate selection process."

The client MUST ignore the list, but MAY take action based upon the
content of the list?

Good catch - you&#= 39;re seeing a bad merge of two different versions of this section. The one= I meant to be in there is the one where the client MUST ignore the list (l= ong story...:-).=A0

I'll collect more comments for now (instead of fixi= ng it right away), but I will make sure that gets fixed in the next draft.<= /div>

Dirk.

=A0

Chris


On Mon, Aug 22, 2011 at 1:53 PM, Dirk Balfanz <balfanz@google.com> wrote:
>
> Dear TLS-WG,
> I few weeks ago I presented a proposal for an "origin-bound certi= ficates" TLS extension at IETF 81. It's much easier to understand = what this extension is trying to accomplish when presented in a broader con= text of web authentication (which I tried to give in Quebec), so I put toge= ther a little web site that is supposed to do just that for those who could= n't be at the IETF meeting: http://browserauth.net (This took me a little while, hence = the delay in sending out the I-D).
> Anyway, here is the I-D:=A0http://tools.ietf.org/html/draft-balfan= z-tls-obc, which I submit for your comments/feedback. (Again, remember = to read http://browser= auth.net for some context.)
> All feedback is welcome, of course, but if you can't think of anyt= hing to comment on, I have a couple particular questions:
> - in Section 2.1.1 we currently stipulate that the client include the = origin of the origin-bound cert as part of the OBC X.509 extension. When we= implemented this, we didn't really know what to do with that data on t= he server side. If the client also uses TLS-SNI, then we could imagine comp= aring the SNI and OBC origins in some manner on the server side, but there = isn't really a vehicle to signal an error back to the client saying &qu= ot;your SNI and OBC origins don't match". Similarly, we could perh= aps at some higher layer compare the HTTP "Host" header with the = OBC origin, but then again - what do you do when they don't match? Resp= ond with a 400 at the HTTP layer? An alternative to the current language in= the I-D would be to simply mark the cert as origin-bound, but without putt= ing the origin itself into the cert. Any thoughts?
> - What do you think of the privacy-enhancing power of using per-origin= certs? The idea there is that different domains see different "identi= ties" (public keys) for the same client. Of course, if two domains cho= ose to collaborate, they can probably find a way to correlate the two ident= ities they see for the same client. This is similar to cookies, where norma= lly "identities" (cookies) for one domain are not revealed to ano= ther domain unless, of course, they choose to collaborate. How much privacy= would we really lose if we just used one certificate for all origins? It w= ould certainly make the design and implementation simpler. (I tend to favor= per-origin certs, but I'm curious as to what other people think.)
> Thanks for your consideration!
> Dirk.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--0016e6407cd6cec15e04ab4e731e-- From balfanz@google.com Wed Aug 24 23:30:15 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E50921F8AF4 for ; Wed, 24 Aug 2011 23:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf2gevS552c3 for ; Wed, 24 Aug 2011 23:30:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 573DD21F8AF2 for ; Wed, 24 Aug 2011 23:30:14 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p7P6VOsd028799 for ; Wed, 24 Aug 2011 23:31:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314253884; bh=VFiOOswkuK45IYI1RuVeogQL0l0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XonMBsvYDBAhOdE5uBna4TdKM3Jsii4kWRiUmlOWaPSaexOWuUpQyvlgeXoY3GH9j vKBEoGhEzJ2o41kfmtpDw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=nFC2XpjFr1kgkFdIG00tf+kiKYod8C55KAIKL5dwlM6TFAb6HazxWFDvzNUkGrghY RVBDk3fdiiqEtjDXpXPMQ== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by hpaq6.eem.corp.google.com with ESMTP id p7P6VL0Z009548 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 24 Aug 2011 23:31:22 -0700 Received: by gyc15 with SMTP id 15so2960161gyc.25 for ; Wed, 24 Aug 2011 23:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tIkOpka2XLt2oBzOYc+u5PCoTjAYkRgk1AaKpfSzAaw=; b=Io0L5wDGwaAaK1sWjBdDR7QUBkSFjpK2r7Z+j7aFZa0Rdrl+Y8DadcKzvEMTKJBQy4 7ON037QSRWVtGIJOyp2Q== Received: by 10.91.47.27 with SMTP id z27mr1600606agj.98.1314253881244; Wed, 24 Aug 2011 23:31:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.47.27 with SMTP id z27mr1600602agj.98.1314253881015; Wed, 24 Aug 2011 23:31:21 -0700 (PDT) Received: by 10.90.56.4 with HTTP; Wed, 24 Aug 2011 23:31:20 -0700 (PDT) In-Reply-To: <7BAD42FE4F789E2903A528D5@nifty-silver.local> References: <7BAD42FE4F789E2903A528D5@nifty-silver.local> Date: Wed, 24 Aug 2011 23:31:20 -0700 Message-ID: From: Dirk Balfanz To: Chris Newman Content-Type: multipart/alternative; boundary=001485f91e0eb8fdac04ab4e93b1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] TLS-OBC proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 06:30:15 -0000 --001485f91e0eb8fdac04ab4e93b1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 23, 2011 at 9:58 PM, Chris Newman wrote: > TLS client certificate authentication is used sometimes with email. Indeed > it's a significant reason this draft is needed: > draft-melnikov-pop3-over-tls-**01.txt. > > Some mail clients associate a single TLS client certificate with a "mail > account" and would not benefit from OBC. Some mail clients store TLS client > certificates in a pool and one has to be selected for a given account when > the server requests a client certificate. Such mail clients would benefit > from OBC. However, the two most widely deployed open source TLS stacks > (OpenSSL & NSS) are changing very slowly. I'm skeptical that OBC provides > enough benefit to actually get implemented and deployed in such TLS stacks. > Do you know of implementers sufficiently interested in the feature that they > would be willing to contribute code to OpenSSL and NSS? > As a proof-of-concept, we're putting support for TLS-OBC both into OpenSSL and NSS. Whether that will ever land in the main branches depends on whether our proof-of-concept is successful (demonstrates acceptable utility and performance), and I guess also to a degree on whether groups like this one find the proposal worthwhile. As you point out, there is a bit of a chicken-and-egg problem going on here, but we _are_ writing the code for this as we speak both for OpenSSL and NSS. Dirk. > > - Chris > > > --On August 22, 2011 10:53:05 -0700 Dirk Balfanz > wrote: > > Dear TLS-WG, >> >> I few weeks ago I presented a proposal for an "origin-bound certificates" >> TLS extension at IETF 81. It's much easier to understand what this >> extension is trying to accomplish when presented in a broader context of >> web authentication (which I tried to give in Quebec), so I put together a >> little web site that is supposed to do just that for those who couldn't >> be at the IETF meeting: http://browserauth.net (This took me a little >> while, hence the delay in sending out the I-D). >> >> Anyway, here is the I-D: http://tools.ietf.org/html/** >> draft-balfanz-tls-obc , >> which I submit for your comments/feedback. (Again, remember to read >> http://browserauth.net for some context.) >> >> All feedback is welcome, of course, but if you can't think of anything to >> comment on, I have a couple particular questions: >> >> - in Section 2.1.1 we currently stipulate that the client include the >> origin of the origin-bound cert as part of the OBC X.509 extension. When >> we implemented this, we didn't really know what to do with that data on >> the server side. If the client also uses TLS-SNI, then we could imagine >> comparing the SNI and OBC origins in some manner on the server side, but >> there isn't really a vehicle to signal an error back to the client saying >> "your SNI and OBC origins don't match". Similarly, we could perhaps at >> some higher layer compare the HTTP "Host" header with the OBC origin, but >> then again - what do you do when they don't match? Respond with a 400 at >> the HTTP layer? An alternative to the current language in the I-D would >> be to simply mark the cert as origin-bound, but without putting the >> origin itself into the cert. Any thoughts? >> >> - What do you think of the privacy-enhancing power of using per-origin >> certs? The idea there is that different domains see different "identities" >> (public keys) for the same client. Of course, if two domains choose to >> collaborate, they can probably find a way to correlate the two identities >> they see for the same client. This is similar to cookies, where normally >> "identities" (cookies) for one domain are not revealed to another domain >> unless, of course, they choose to collaborate. How much privacy would we >> really lose if we just used one certificate for all origins? It would >> certainly make the design and implementation simpler. (I tend to favor >> per-origin certs, but I'm curious as to what other people think.) >> >> Thanks for your consideration! >> >> Dirk. >> >> > > > > --001485f91e0eb8fdac04ab4e93b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 9:58 PM, Chris Newman <chris.newman@oracle.com> = wrote:
TLS client certificate authentication is used sometimes with email. Indeed = it's a significant reason this draft is needed: draft-melnikov-pop3-ove= r-tls-01.txt.

Some mail clients associate a single TLS client certificate with a "ma= il account" and would not benefit from OBC. Some mail clients store TL= S client certificates in a pool and one has to be selected for a given acco= unt when the server requests a client certificate. Such mail clients would = benefit from OBC. However, the two most widely deployed open source TLS sta= cks (OpenSSL & NSS) are changing very slowly. I'm skeptical that OB= C provides enough benefit to actually get implemented and deployed in such = TLS stacks. Do you know of implementers sufficiently interested in the feat= ure that they would be willing to contribute code to OpenSSL and NSS?

As a proof-of-concept, we're putting s= upport for TLS-OBC both into OpenSSL and NSS. Whether that will ever land i= n the main branches depends on whether our proof-of-concept is successful (= demonstrates acceptable utility and performance), and I guess also to a deg= ree on whether groups like this one find the proposal worthwhile. As you po= int out, there is a bit of a chicken-and-egg problem going on here, but we = _are_ writing the code for this as we speak both for OpenSSL and NSS.

Dirk.

=A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Chris
=


--On August 22, 2011 10:53:05 -0700 Dirk Balfanz <balfanz@google.com> wrote:

Dear TLS-WG,

I few weeks ago I presented a proposal for an "origin-bound certificat= es"
TLS extension at IETF 81. It's much easier to understand what this
extension is trying to accomplish when presented in a broader context of web authentication (which I tried to give in Quebec), so I put together a little web site that is supposed to do just that for those who couldn't=
be at the IETF meeting: http://browserauth.net (This took me a little
while, hence the delay in sending out the I-D).

Anyway, here is the I-D: http://tools.ietf.org/html/draft-balfan= z-tls-obc,
which I submit for your comments/feedback. (Again, remember to read
http://browserauth.net= for some context.)

All feedback is welcome, of course, but if you can't think of anything = to
comment on, I have a couple particular questions:

- in Section 2.1.1 we currently stipulate that the client include the
origin of the origin-bound cert as part of the OBC X.509 extension. When we implemented this, we didn't really know what to do with that data on=
the server side. If the client also uses TLS-SNI, then we could imagine
comparing the SNI and OBC origins in some manner on the server side, but there isn't really a vehicle to signal an error back to the client sayi= ng
"your SNI and OBC origins don't match". Similarly, we could p= erhaps at
some higher layer compare the HTTP "Host" header with the OBC ori= gin, but
then again - what do you do when they don't match? Respond with a 400 a= t
the HTTP layer? An alternative to the current language in the I-D would
be to simply mark the cert as origin-bound, but without putting the
origin itself into the cert. Any thoughts?

- What do you think of the privacy-enhancing power of using per-origin
certs? The idea there is that different domains see different "identit= ies"
(public keys) for the same client. Of course, if two domains choose to
collaborate, they can probably find a way to correlate the two identities they see for the same client. This is similar to cookies, where normally "identities" (cookies) for one domain are not revealed to another= domain
unless, of course, they choose to collaborate. How much privacy would we really lose if we just used one certificate for all origins? It would
certainly make the design and implementation simpler. (I tend to favor
per-origin certs, but I'm curious as to what other people think.)

Thanks for your consideration!

Dirk.






--001485f91e0eb8fdac04ab4e93b1-- From ynir@checkpoint.com Thu Aug 25 00:38:49 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA03E21F86AF for ; Thu, 25 Aug 2011 00:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.354 X-Spam-Level: X-Spam-Status: No, score=-10.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm-lDaLlix3a for ; Thu, 25 Aug 2011 00:38:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A724221F85C4 for ; Thu, 25 Aug 2011 00:38:48 -0700 (PDT) X-CheckPoint: {4E5609A3-B-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p7P7dxeJ002655 for ; Thu, 25 Aug 2011 10:39:59 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 25 Aug 2011 10:40:00 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 25 Aug 2011 10:39:59 +0300 From: Yoav Nir To: "tls@ietf.org List" Date: Thu, 25 Aug 2011 10:39:57 +0300 Thread-Topic: TLS and middleboxes again Thread-Index: Acxi+jEJsi2tW17kStmHEBs1a54z6Q== Message-ID: <036F4DE5-2E91-4946-87E2-F3258038E511@checkpoint.com> References: <20110825073046.30318.5618.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 07:38:49 -0000 Hi all Several weeks ago, Dave McGrew submitted a draft for improving the workings= of TLS proxies. As expected, this generated a lot of controversy, with som= e people saying that they'd rather hand over the session keys to the middle= box than to standardize a MitM attack. I was on the other side of that debate, but one problem with comparing the = two alternatives is that for proxies there are several commercial products = and Dave's draft, while there's nothing for key sharing. To remedy that, an= d help the discussion along, I've submitted the below draft. Comments and a= dditional controversy are very welcome. Yoav Begin forwarded message: > From: "internet-drafts@ietf.org" > Date: August 25, 2011 10:30:46 AM GMT+03:00 > To: "i-d-announce@ietf.org" > Subject: I-D Action: draft-nir-tls-keyshare-00.txt > Reply-To: "internet-drafts@ietf.org" >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : A Method for Sharing Record Protocol Keys with a Middl= ebox in TLS > Author(s) : Yoav Nir > Filename : draft-nir-tls-keyshare-00.txt > Pages : 11 > Date : 2011-08-25 >=20 > This document contains a straw man proposal for a method for sharing > symmetric session keys between a TLS client and a middlebox, so that > the middlebox can decrypt the TLS-protected traffic. >=20 > This method is an alternative to the middlebox becoming a proxy. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-tls-keyshare-00.txt From yaronf.ietf@gmail.com Fri Aug 26 02:16:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3042E21F881C for ; Fri, 26 Aug 2011 02:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpgV68rktqhT for ; Fri, 26 Aug 2011 02:16:17 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3039921F87E2 for ; Fri, 26 Aug 2011 02:16:17 -0700 (PDT) Received: by wwe5 with SMTP id 5so289836wwe.1 for ; Fri, 26 Aug 2011 02:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Uk5HukZuONlBa8HX7vK+BfVWlOHneIz0f+kbK/sbS+Q=; b=NvP9DM8nRo3kk8kCL7H2i8cuNU2D8Secra/KjXqGblXEYsJFbz6iT425z1SqxPEg0X 3sPlrpPEuJ0RsG1KG7DAeEFWzzXuTchEcBb7u1cYSitIGr7AuDY4JVdy/CxBUnUp8QNL GP6Xx0cG9Huf60diXeGwRkCifEa70Ub1FPH5o= Received: by 10.227.121.136 with SMTP id h8mr679327wbr.82.1314350250794; Fri, 26 Aug 2011 02:17:30 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-181-242-252.red.bezeqint.net [79.181.242.252]) by mx.google.com with ESMTPS id fh17sm1131908wbb.37.2011.08.26.02.17.28 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 02:17:30 -0700 (PDT) Message-ID: <4E5764A6.8080701@gmail.com> Date: Fri, 26 Aug 2011 12:17:26 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 09:16:18 -0000 Hi, I support this proposal. I think it is a lot more generic than the previous one, since it also supports mutual authentication (TLS-SRP) and client certs. A few comments: - On top of the encryption keys, we probably need to support sending the MAC keys. Subject to client and server policy of course. - I think the idea of pushing records into the stream only works for the initial handshake, before the Change Cipher Spec message. Later on (re-handshake) this would not work because of the ongoing sequence number that's MACed with each record. - IMHO the following sentence is miguided, and opens a major security loophole: "If a KeyShareInfo record is received with an unknown certificate, [...] the user MAY be prompted to authorize the decryption, and optionally change the configuration to allow future decryption by this certificate." Users will always say Yes when otherwise their communication will be interrupted. In other words, the proxy certificates must only be provisioned off-line, in advance, when the user can still make reasoned decisions. [As an example of this user behavior, I just approved myself the IETF's own expired certificate...] Thanks, Yaron On 08/25/2011 10:00 PM, tls-request@ietf.org wrote: > ------------------------------ > > Message: 2 > Date: Thu, 25 Aug 2011 10:39:57 +0300 > From: Yoav Nir > To:"tls@ietf.org List" > Subject: [TLS] TLS and middleboxes again > Message-ID:<036F4DE5-2E91-4946-87E2-F3258038E511@checkpoint.com> > Content-Type: text/plain; charset="us-ascii" > > Hi all > > Several weeks ago, Dave McGrew submitted a draft for improving the workings of TLS proxies. As expected, this generated a lot of controversy, with some people saying that they'd rather hand over the session keys to the middlebox than to standardize a MitM attack. > > I was on the other side of that debate, but one problem with comparing the two alternatives is that for proxies there are several commercial products and Dave's draft, while there's nothing for key sharing. To remedy that, and help the discussion along, I've submitted the below draft. Comments and additional controversy are very welcome. > > Yoav > > Begin forwarded message: > >> From:"internet-drafts@ietf.org" >> Date: August 25, 2011 10:30:46 AM GMT+03:00 >> To:"i-d-announce@ietf.org" >> Subject: I-D Action: draft-nir-tls-keyshare-00.txt >> Reply-To:"internet-drafts@ietf.org" >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : A Method for Sharing Record Protocol Keys with a Middlebox in TLS >> Author(s) : Yoav Nir >> Filename : draft-nir-tls-keyshare-00.txt >> Pages : 11 >> Date : 2011-08-25 >> >> This document contains a straw man proposal for a method for sharing >> symmetric session keys between a TLS client and a middlebox, so that >> the middlebox can decrypt the TLS-protected traffic. >> >> This method is an alternative to the middlebox becoming a proxy. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nir-tls-keyshare-00.txt > ------------------------------ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > End of TLS Digest, Vol 85, Issue 18 > *********************************** From juhovh@iki.fi Fri Aug 26 03:52:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25021F8B4C for ; Fri, 26 Aug 2011 03:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkCavpLUpLz9 for ; Fri, 26 Aug 2011 03:52:32 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E321F8B50 for ; Fri, 26 Aug 2011 03:52:32 -0700 (PDT) Received: from mail.visino.fi (88.192.37.90) by jenni1.inet.fi (8.5.133) id 4DF73B28035C768F for tls@ietf.org; Fri, 26 Aug 2011 13:53:44 +0300 Received: from [130.233.194.212] (tko-add-212.cs.hut.fi [130.233.194.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 675D01FE9D for ; Fri, 26 Aug 2011 13:53:44 +0300 (EEST) Message-ID: <4E577B25.3040302@iki.fi> Date: Fri, 26 Aug 2011 13:53:25 +0300 From: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: tls@ietf.org References: <4E5764A6.8080701@gmail.com> In-Reply-To: <4E5764A6.8080701@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 10:52:33 -0000 26.8.2011 12:17, Yaron Sheffer kirjoitti: > I support this proposal. I think it is a lot more generic than the > previous one, since it also supports mutual authentication (TLS-SRP) > and client certs. I support it as well, it sounds very similar to what I was working on a while back. I needed to sniff SSL traffic with Wireshark for debugging purposes, but the problem was that I could only sniff the connections that were doing an RSA key exchange with my own certificate, so that I could give the private key to Wireshark. Connections where I used my client to connect to a third party server or connections using DHE wouldn't work at all. How I solved this was to use the weakness in TLS 1.0 and TLS 1.1 which allows to inject TLS records with an unknown type into the stream without breaking the connection, to prevent TLS 1.2 from being used I could simply disable it from my client. I then used that record to pass the decryption keys to Wireshark and got the connections in plain text without any modifications to the actual software, just had to replace the libssl or such in the client side. I think it's a good idea to standardize a way for key sharing, there's a lot of reasons to allow decryption of the traffic for one party in the middle if the user gives consent. It shouldn't be too easy to enable though and users of it should be well aware of what they are doing. > A few comments: > - On top of the encryption keys, we probably need to support sending > the MAC keys. Subject to client and server policy of course. I have no reason to support sending the MAC keys, and letting the proxy to modify the actual contents of the connection sounds a bit scary to me... What's the actual use case for this? I'm sure there's some, but I can't think of anything sensible right now. Basically sharing the MAC keys would make it similar with the certificate MitM attack currently used. > - I think the idea of pushing records into the stream only works for > the initial handshake, before the Change Cipher Spec message. Later on > (re-handshake) this would not work because of the ongoing sequence > number that's MACed with each record. That's a very good point, I don't think injecting records works after the initial handshake either. Then again on subsequent handshakes the certificate and signature info doesn't need to be sent, only the actual KeyShareInfo(keys) record is relevant. Current specification says that record is removed by middlebox, but if it were NOT removed, it would work without problems on re-handshakes as well. If the KeyShareInfo(keys) is properly RSA encrypted with the middlebox private key, it shouldn't impose any real threat to the connection as long as the middlebox private key is considered safe. > - IMHO the following sentence is miguided, and opens a major security > loophole: "If a KeyShareInfo record is received with an unknown > certificate, [...] the user MAY be prompted to authorize the > decryption, and optionally change the configuration to allow future > decryption by this certificate." Users will always say Yes when > otherwise their communication will be interrupted. In other words, the > proxy certificates must only be provisioned off-line, in advance, when > the user can still make reasoned decisions. [As an example of this > user behavior, I just approved myself the IETF's own expired > certificate...] I'm not sure if KeyShareInfo with an unknown certificate should ever be allowed... Configuring it as authorized might be even worse idea. Thank you for the draft anyway, I think if implemented widely it would be a better option than the proxy certificate currently used, because it's much better to be able to only share the decryption keys without the MAC keys. Juho > > Thanks, > Yaron > > > On 08/25/2011 10:00 PM, tls-request@ietf.org wrote: >> ------------------------------ >> >> Message: 2 >> Date: Thu, 25 Aug 2011 10:39:57 +0300 >> From: Yoav Nir >> To:"tls@ietf.org List" >> Subject: [TLS] TLS and middleboxes again >> Message-ID:<036F4DE5-2E91-4946-87E2-F3258038E511@checkpoint.com> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all >> >> Several weeks ago, Dave McGrew submitted a draft for improving the >> workings of TLS proxies. As expected, this generated a lot of >> controversy, with some people saying that they'd rather hand over the >> session keys to the middlebox than to standardize a MitM attack. >> >> I was on the other side of that debate, but one problem with >> comparing the two alternatives is that for proxies there are several >> commercial products and Dave's draft, while there's nothing for key >> sharing. To remedy that, and help the discussion along, I've >> submitted the below draft. Comments and additional controversy are >> very welcome. >> >> Yoav >> >> Begin forwarded message: >> >>> From:"internet-drafts@ietf.org" >>> Date: August 25, 2011 10:30:46 AM GMT+03:00 >>> To:"i-d-announce@ietf.org" >>> Subject: I-D Action: draft-nir-tls-keyshare-00.txt >>> Reply-To:"internet-drafts@ietf.org" >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : A Method for Sharing Record Protocol Keys with >>> a Middlebox in TLS >>> Author(s) : Yoav Nir >>> Filename : draft-nir-tls-keyshare-00.txt >>> Pages : 11 >>> Date : 2011-08-25 >>> >>> This document contains a straw man proposal for a method for sharing >>> symmetric session keys between a TLS client and a middlebox, so that >>> the middlebox can decrypt the TLS-protected traffic. >>> >>> This method is an alternative to the middlebox becoming a proxy. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-nir-tls-keyshare-00.txt >> ------------------------------ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >> End of TLS Digest, Vol 85, Issue 18 >> *********************************** > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From n.mavrogiannopoulos@gmail.com Fri Aug 26 08:47:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEBE21F8BB2 for ; Fri, 26 Aug 2011 08:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMU0ciuAyHhi for ; Fri, 26 Aug 2011 08:47:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2133321F88B7 for ; Fri, 26 Aug 2011 08:47:49 -0700 (PDT) Received: by wwf5 with SMTP id 5so2445242wwf.13 for ; Fri, 26 Aug 2011 08:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=STaOTgmqUseBzbFNBmVBRnYYhQyzLdD2UWwNbQOWtJo=; b=UkQLSzbQHezWl4rTwBlA4rFOWnuNYrxphN9H3xdBhhVGPJAUwpELzJHznbAzLFXbWO amOt76mpfYhn8IC0VMGUez3Wc2wPFtF3XtKth8EtbT4hbCfzohirS92CYsyi9FSZ74UD bWsBVJOqrwXH3JiYNEwhgeUB7DNFfGH+QWLTY= Received: by 10.216.24.31 with SMTP id w31mr1023566wew.67.1314373074309; Fri, 26 Aug 2011 08:37:54 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id z74sm1114352weq.23.2011.08.26.08.37.52 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 08:37:53 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E57BDCF.7050307@gnutls.org> Date: Fri, 26 Aug 2011 17:37:51 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= References: <4E5764A6.8080701@gmail.com> <4E577B25.3040302@iki.fi> In-Reply-To: <4E577B25.3040302@iki.fi> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:47:51 -0000 On 08/26/2011 12:53 PM, Juho Vähä-Herttua wrote: >> A few comments: >> - On top of the encryption keys, we probably need to support sending >> the MAC keys. Subject to client and server policy of course. > I have no reason to support sending the MAC keys, and letting the proxy > to modify the actual contents of the connection sounds a bit scary to > me... What's the actual use case for this? I'm sure there's some, but I > can't think of anything sensible right now. Basically sharing the MAC > keys would make it similar with the certificate MitM attack currently used. Or maybe a different MAC key is provided to the middle box, which will use this to rewrite a MAC message (and tag it with a different content-type such as modified-record). That way the client will know whether the packet received is original or modified. regards, Nikos From prvs=7219dbd7e4=uri@ll.mit.edu Fri Aug 26 09:10:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF5F21F85A1 for ; Fri, 26 Aug 2011 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGWJ0Vu8aP2T for ; Fri, 26 Aug 2011 09:10:56 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8921F850E for ; Fri, 26 Aug 2011 09:10:51 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p7QGBjYn018055; Fri, 26 Aug 2011 12:11:45 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "'nmav@gnutls.org'" , "'juhovh@iki.fi'" Date: Fri, 26 Aug 2011 12:11:44 -0400 Thread-Topic: [TLS] TLS and middleboxes again Thread-Index: AcxkB8AbP0+DJMznS4mpjOUeIO7yCwAAxltb In-Reply-To: <4E57BDCF.7050307@gnutls.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-26_05:2011-08-26, 2011-08-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=6 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108260141 Message-Id: <20110826161051.85A8921F850E@ietfa.amsl.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:10:56 -0000 There COULD be justifiable need to observe the traffic and thus to share th= e encryption key. At this time I see _no_ justifiable need to modify the tr= affic and thus believe that the MAC key must not be shared with the third p= arties.=20 If there's something wrong with the content - force the connection to close= /abort. =20 -- Regards, Uri ----- Original Message ----- From: Nikos Mavrogiannopoulos [mailto:nmav@gnutls.org] Sent: Friday, August 26, 2011 11:37 AM=0A= To: Juho V=E4h=E4-Herttua Cc: tls@ietf.org Subject: Re: [TLS] TLS and middleboxes again On 08/26/2011 12:53 PM, Juho V=E4h=E4-Herttua wrote: >> A few comments: >> - On top of the encryption keys, we probably need to support sending >> the MAC keys. Subject to client and server policy of course. > I have no reason to support sending the MAC keys, and letting the proxy > to modify the actual contents of the connection sounds a bit scary to > me... What's the actual use case for this? I'm sure there's some, but I > can't think of anything sensible right now. Basically sharing the MAC > keys would make it similar with the certificate MitM attack currently use= d. Or maybe a different MAC key is provided to the middle box, which will use this to rewrite a MAC message (and tag it with a different content-type such as modified-record). That way the client will know whether the packet received is original or modified. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From yaronf.ietf@gmail.com Fri Aug 26 13:03:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3925C21F8BA6 for ; Fri, 26 Aug 2011 13:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgHyPBYaH99M for ; Fri, 26 Aug 2011 13:03:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6077921F8AFB for ; Fri, 26 Aug 2011 13:03:26 -0700 (PDT) Received: by wwf5 with SMTP id 5so2603503wwf.13 for ; Fri, 26 Aug 2011 13:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xXQ/vtAhD3ODjNoIvJ6sc+vLU+q79hyAGh2l5R3Vx2s=; b=oWD+9KerhtyOpYApGufMywIcTIyfXhKf6qLPaKeTKjq+YWrZOmbx6FZVN8nd534Bcr TpUev/XBnOFsbJwDswmbSplDrpH4RwWYKRFj8TRiP/wkvA6PZ5JN7y2jmC7hcrQ5xFD7 /XtgUl2zOU+ebx0VUaNjtinGURCoKJpRCHyhM= Received: by 10.227.37.87 with SMTP id w23mr1313633wbd.55.1314389082709; Fri, 26 Aug 2011 13:04:42 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-242-252.red.bezeqint.net [79.181.242.252]) by mx.google.com with ESMTPS id n20sm1568900wbh.33.2011.08.26.13.04.40 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 13:04:41 -0700 (PDT) Message-ID: <4E57FC4B.3080809@gmail.com> Date: Fri, 26 Aug 2011 23:04:27 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:03:27 -0000 Hi Uri, two reasons for the middlebox to use the MAC (which may or may not be "justifiable" to you) are: - Many security applications add a textual signature similar to "This mail was scanned by The Best Antivirus". - If something bad is detected in the traffic, the middlebox might want to issue an HTTP redirect, e.g. to display a copy of the company's security policy. And I like Nikos' idea of having a different MAC for middlebox-generated traffic. Although sharing the middlebox-specific MAC with the individual middlebox AND with the server, while not sharing it with other middleboxes along the path (yes the draft assumes there could be several) would be a challenge. Thanks, Yaron On 26.8.2011 22:00, tls-request@ietf.org wrote: > > ------------------------------ > > Message: 4 > Date: Fri, 26 Aug 2011 12:11:44 -0400 > From: "Blumenthal, Uri - 0668 - MITLL" > To: "'nmav@gnutls.org'", "'juhovh@iki.fi'" > > Cc: "'tls@ietf.org'" > Subject: Re: [TLS] TLS and middleboxes again > Message-ID:<20110826161051.85A8921F850E@ietfa.amsl.com> > Content-Type: text/plain; charset="iso-8859-1" > > There COULD be justifiable need to observe the traffic and thus to share the encryption key. At this time I see _no_ justifiable need to modify the traffic and thus believe that the MAC key must not be shared with the third parties. > > If there's something wrong with the content - force the connection to close/abort. > > -- > Regards, > Uri > > ----- Original Message ----- > From: Nikos Mavrogiannopoulos [mailto:nmav@gnutls.org] > Sent: Friday, August 26, 2011 11:37 AM > To: Juho V?h?-Herttua > Cc: tls@ietf.org > Subject: Re: [TLS] TLS and middleboxes again > > On 08/26/2011 12:53 PM, Juho V?h?-Herttua wrote: > >>> A few comments: >>> - On top of the encryption keys, we probably need to support sending >>> the MAC keys. Subject to client and server policy of course. >> I have no reason to support sending the MAC keys, and letting the proxy >> to modify the actual contents of the connection sounds a bit scary to >> me... What's the actual use case for this? I'm sure there's some, but I >> can't think of anything sensible right now. Basically sharing the MAC >> keys would make it similar with the certificate MitM attack currently used. > Or maybe a different MAC key is provided to the middle box, which will > use this to rewrite a MAC message (and tag it with a different > content-type such as modified-record). > > That way the client will know whether the packet received is original > or modified. > > > regards, > Nikos > _______________________________________________ > 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 > > > End of TLS Digest, Vol 85, Issue 19 > *********************************** From ynir@checkpoint.com Fri Aug 26 13:19:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F7D21F8C7B for ; Fri, 26 Aug 2011 13:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgSN20UmMkOu for ; Fri, 26 Aug 2011 13:19:39 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E7B5E21F8B5F for ; Fri, 26 Aug 2011 13:19:38 -0700 (PDT) X-CheckPoint: {4E580D76-3-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p7QKKr8H029816; Fri, 26 Aug 2011 23:20:54 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 26 Aug 2011 23:20:54 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 26 Aug 2011 23:20:53 +0300 From: Yoav Nir To: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= Date: Fri, 26 Aug 2011 23:20:51 +0300 Thread-Topic: [TLS] TLS and middleboxes again Thread-Index: AcxkLadSw2sGw1QVQCqFMMaUutwe4w== Message-ID: <26DC6964-8FEE-469B-8F51-68241C4A3320@checkpoint.com> References: <4E5764A6.8080701@gmail.com> <4E577B25.3040302@iki.fi> In-Reply-To: <4E577B25.3040302@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:19:40 -0000 On Aug 26, 2011, at 1:53 PM, Juho V=E4h=E4-Herttua wrote: > 26.8.2011 12:17, Yaron Sheffer kirjoitti: >> I support this proposal. I think it is a lot more generic than the=20 >> previous one, since it also supports mutual authentication (TLS-SRP)=20 >> and client certs. >=20 > I support it as well, This is meant as a straw man proposal. I still think that an actual proxy i= s better. >> A few comments: >> - On top of the encryption keys, we probably need to support sending=20 >> the MAC keys. Subject to client and server policy of course. >=20 > I have no reason to support sending the MAC keys, and letting the proxy=20 > to modify the actual contents of the connection sounds a bit scary to=20 > me... What's the actual use case for this? An attacker sends your gmail (or hotmail, of iCloud) account a document con= taining malicious macros. You click the document link within the website to= download it. The middlebox detects the malware. Without MAC keys, it can o= nly break the connection, which looks weird - like the download has failed.= With MAC keys, it can redirect to a page that says "The file you tried to = download contains the XXXXX virus", or it can even let you download a docum= ent that says that. >=20 >> - IMHO the following sentence is miguided, and opens a major security=20 >> loophole: "If a KeyShareInfo record is received with an unknown=20 >> certificate, [...] the user MAY be prompted to authorize the=20 >> decryption, and optionally change the configuration to allow future=20 >> decryption by this certificate." Users will always say Yes when=20 >> otherwise their communication will be interrupted. In other words, the=20 >> proxy certificates must only be provisioned off-line, in advance, when=20 >> the user can still make reasoned decisions. [As an example of this=20 >> user behavior, I just approved myself the IETF's own expired=20 >> certificate...] >=20 > I'm not sure if KeyShareInfo with an unknown certificate should ever be=20 > allowed... Configuring it as authorized might be even worse idea. Thank=20 > you for the draft anyway, I think if implemented widely it would be a=20 > better option than the proxy certificate currently used, because it's=20 > much better to be able to only share the decryption keys without the MAC= =20 > keys. I agree that configuration is a difficult issue, but I don't see how we can= take the user out of the loop. I don't want to allow Starbucks to decrypt = my TLS traffic, but I will probably accept this from my employer. These day= s we have a lot of unmanaged hardware at companies (a lot of Macs, and almo= st all cell-phones) and even more unmanaged browsers.=20 From ynir@checkpoint.com Fri Aug 26 13:26:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC5821F8C9D for ; Fri, 26 Aug 2011 13:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.36 X-Spam-Level: X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT+q-81BrnR0 for ; Fri, 26 Aug 2011 13:26:41 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 65FDE21F8C99 for ; Fri, 26 Aug 2011 13:26:41 -0700 (PDT) X-CheckPoint: {4E580F1C-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p7QKRsie030530; Fri, 26 Aug 2011 23:27:54 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 26 Aug 2011 23:27:54 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 26 Aug 2011 23:27:54 +0300 From: Yoav Nir To: Yaron Sheffer Date: Fri, 26 Aug 2011 23:27:52 +0300 Thread-Topic: [TLS] TLS and middleboxes again Thread-Index: AcxkLqJFWF+j9ptiQTGecxQFg9JpjA== Message-ID: <485D9A10-318C-4202-B171-D3C2BC5FA3DB@checkpoint.com> References: <4E57FC4B.3080809@gmail.com> In-Reply-To: <4E57FC4B.3080809@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:26:42 -0000 On Aug 26, 2011, at 11:04 PM, Yaron Sheffer wrote: > Hi Uri, >=20 > two reasons for the middlebox to use the MAC (which may or may not be=20 > "justifiable" to you) are: >=20 > - Many security applications add a textual signature similar to "This=20 > mail was scanned by The Best Antivirus". > - If something bad is detected in the traffic, the middlebox might want=20 > to issue an HTTP redirect, e.g. to display a copy of the company's=20 > security policy. >=20 > And I like Nikos' idea of having a different MAC for middlebox-generated= =20 > traffic. Although sharing the middlebox-specific MAC with the individual= =20 > middlebox AND with the server, while not sharing it with other=20 > middleboxes along the path (yes the draft assumes there could be=20 > several) would be a challenge. Only if you require the other middleboxes to verify the MAC. If the MAC for= the middlebox is derived from the master secret (for example, with an extr= actor), the server can automatically calculate it. But once you've begun to= make changes, you likely have to re-MAC all subsequent records, because it= 's likely that the modified content takes a different amount of records, an= d then the sequence number count is off. From dkg@fifthhorseman.net Fri Aug 26 13:44:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A79321F8C9F for ; Fri, 26 Aug 2011 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scvPY866g7IZ for ; Fri, 26 Aug 2011 13:44:21 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62121F8C93 for ; Fri, 26 Aug 2011 13:44:21 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 4F90CF970 for ; Fri, 26 Aug 2011 16:45:35 -0400 (EDT) Message-ID: <4E5805EC.6000904@fifthhorseman.net> Date: Fri, 26 Aug 2011 16:45:32 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0 MIME-Version: 1.0 To: tls@ietf.org References: <4E57FC4B.3080809@gmail.com> In-Reply-To: <4E57FC4B.3080809@gmail.com> X-Enigmail-Version: 1.2.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6A08B68326482A42F451AF92" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 26 Aug 2011 20:44:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6A08B68326482A42F451AF92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/26/2011 04:04 PM, Yaron Sheffer wrote: > two reasons for the middlebox to use the MAC (which may or may not be > "justifiable" to you) are: >=20 > - Many security applications add a textual signature similar to "This > mail was scanned by The Best Antivirus". Just to be clear, this approach has no security value unless they also actively filter *out* any and all content which might be rendered as "This mail was scanned by The Best Antivirus". Otherwise, it's trivial for an attacker to include the string in their initial mail. And frankly, with HTML e-mail these days, i suspect it would be rather difficult to match all strings that might render to something visually indistinguishable from this. and difficult to excise them cleanly without damaging other content. Once an antivirus starts actively tampering with content, i think it's beyond its useful scope, regardless of the TLS implementations. Keep the communication channels separate, thanks. > - If something bad is detected in the traffic, the middlebox might want= =20 > to issue an HTTP redirect, e.g. to display a copy of the company's=20 > security policy. Since HTTP redirects can only be done in an HTTP header, the middlebox would need to buffer all HTTP content before relaying it to the User Agent, in case "bad" material was found at the end. I don't think either of these use cases are valuable, certainly not valuable enough to warrant allowing middleboxes to violate the integrity guarantees of TLS. --dkg --------------enig6A08B68326482A42F451AF92 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJOWAXsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpEgUQAI9ohhlryH82nwJHhYhZd3nQ affUf+WDWXEnqG0sQ5348ugJ7TTKj57iUpHu5pXbBNjX2FkqX4dVLlzuU3Xbsh7L FSbuhJpWXST1rIAG/coygD9gjndAgp7brlDUj2wQ3yT/TsW1Q5KZKo71f0Lfidj+ wtWftD6PBvNXMRaBFi26nMomVqLc5F+scmt9uiA2yxK++GCdmj0sM1r61+ArDW7+ DJ8vwXlE1rX0u5z210le4rRP4xVTaESOUTSiHwytzTPrFaVDAh05MCYZZpwALmz8 GUieAbLQztTp0kSCoPm0fafx01zdE6Qzdqh2G0nRrahW5QkccOa7SvJI3T7Hpsby rBgkT9G29ajdUjTttFDG6rOU1FFYO0O/ogYXVzaFtdGsLmiXepmEtoZQVyBAO9sK WbcwkZqBvXmCilcoOQfv1hgCeYyzPBv3JHD2dKwyBPnchAp73h9vjgACQYl+gT/m sIpljePofKPFGEsu+bC6f+puhqwpB1gFksP4/ls8mzOcd8ns3TE7qjVFmxcRdDm1 zwA7AZBO5nYxx4FKwBR+0Mw8rKjotPVF0HW6ZBqglxnhwK+JzLGTkqYD1H+nyjQ4 qORWsuwLa2v3vnM+AvUI0oLLHlim5jkjDiSKL9goKWo2tMvF9xnyJXWGJEGIMiaI Vpy9UJTNErT22Uo4xi4m =EoJd -----END PGP SIGNATURE----- --------------enig6A08B68326482A42F451AF92-- From prvs=7219dbd7e4=uri@ll.mit.edu Fri Aug 26 16:54:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4AD21F8AF6 for ; Fri, 26 Aug 2011 16:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWug0lr3XSlK for ; Fri, 26 Aug 2011 16:54:46 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 421CC21F8AF4 for ; Fri, 26 Aug 2011 16:54:46 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p7QNtsYi006822 for ; Fri, 26 Aug 2011 19:55:54 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "'tls@ietf.org'" Date: Fri, 26 Aug 2011 19:55:53 -0400 Thread-Topic: [TLS] TLS and middleboxes again Thread-Index: AcxkMSF+WsqOs1IHSd64Kf/oWNOYHgAGo70D In-Reply-To: <4E5805EC.6000904@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-26_05:2011-08-26, 2011-08-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108260241 Message-Id: <20110826235446.421CC21F8AF4@ietfa.amsl.com> Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 23:54:47 -0000 I agree with Daniel.=20 -- Regards, Uri ----- Original Message ----- From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net] Sent: Friday, August 26, 2011 04:45 PM=0A= To: tls@ietf.org Subject: Re: [TLS] TLS and middleboxes again On 08/26/2011 04:04 PM, Yaron Sheffer wrote: > two reasons for the middlebox to use the MAC (which may or may not be > "justifiable" to you) are: >=20 > - Many security applications add a textual signature similar to "This > mail was scanned by The Best Antivirus". Just to be clear, this approach has no security value unless they also actively filter *out* any and all content which might be rendered as "This mail was scanned by The Best Antivirus". Otherwise, it's trivial for an attacker to include the string in their initial mail. And frankly, with HTML e-mail these days, i suspect it would be rather difficult to match all strings that might render to something visually indistinguishable from this. and difficult to excise them cleanly without damaging other content. Once an antivirus starts actively tampering with content, i think it's beyond its useful scope, regardless of the TLS implementations. Keep the communication channels separate, thanks. > - If something bad is detected in the traffic, the middlebox might want=20 > to issue an HTTP redirect, e.g. to display a copy of the company's=20 > security policy. Since HTTP redirects can only be done in an HTTP header, the middlebox would need to buffer all HTTP content before relaying it to the User Agent, in case "bad" material was found at the end. I don't think either of these use cases are valuable, certainly not valuable enough to warrant allowing middleboxes to violate the integrity guarantees of TLS. --dkg From mike-list@pobox.com Fri Aug 26 17:38:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E821F8AF4 for ; Fri, 26 Aug 2011 17:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbwZgJmo8U7J for ; Fri, 26 Aug 2011 17:38:03 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1B67621F8AE9 for ; Fri, 26 Aug 2011 17:38:00 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 2037450B1 for ; Fri, 26 Aug 2011 20:39:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :content-type:content-transfer-encoding:date:from:to:subject :in-reply-to:references:message-id; s=sasl; bh=w/DMmajaWbc1iIig+ aXUzmBeyhE=; b=QBdbZ6X9g0iMfnwF0CbUbUAXZFPAaBbXqfCfQitCipVM1SZrn q4roz2HGjq/t8P53WemLyKNID7aB0Dxv5aABL9yPaJnNL513HYE/WSYthpgzPsw5 NW5RjoPi9h8Q4YK7bGrtd0RgNJwOJI07Z3sIV3lKoYDSAXgKyqZwgPqfAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :content-type:content-transfer-encoding:date:from:to:subject :in-reply-to:references:message-id; q=dns; s=sasl; b=lF7eHBwjzRO gHuJkQU+wqhx+01l5uvV0qSCab1Kwk4loRfGnfzPLCWcx2ZL2TqY8PoXX6Se2ZnH Mk8Y1NviBKA1K0BW2Rx3dpqPprBDEccMTdz0tgULapeLaiMSvy9KE+BP4jhVuUpj uai9ynDCwvOGEh+Wr+ytPoBB5eX/homQ= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 172BC50B0 for ; Fri, 26 Aug 2011 20:39:17 -0400 (EDT) Received: from webmail.pobox.com (unknown [208.72.237.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id D8F3650AF for ; Fri, 26 Aug 2011 20:39:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 26 Aug 2011 20:38:35 -0400 From: Michael D'Errico To: In-Reply-To: <20110826235446.421CC21F8AF4@ietfa.amsl.com> References: <20110826235446.421CC21F8AF4@ietfa.amsl.com> Message-ID: <2772e055daa79988a4fa890a198e4c52@pobox.com> X-Sender: mike-list@pobox.com User-Agent: RoundCube Webmail/0.3-RC1 X-Pobox-Relay-ID: FE9A3102-D044-11E0-885E-1DC62E706CDE-38729857!b-pb-sasl-quonix.pobox.com Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 27 Aug 2011 00:38:03 -0000 I'm also against allowing a middlebox to modify anything (undetectably). Any spec that allowed that could not legitimately be called a TLS "extension" but rather a "subversion". Mike On Fri, 26 Aug 2011 19:55:53 -0400, Blumenthal, Uri - 0668 - MITLL wrote: > I agree with Daniel. > > -- > Regards, > Uri > > ----- Original Message ----- > From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net] > Sent: Friday, August 26, 2011 04:45 PM > To: tls@ietf.org > Subject: Re: [TLS] TLS and middleboxes again > > On 08/26/2011 04:04 PM, Yaron Sheffer wrote: >> two reasons for the middlebox to use the MAC (which may or may not >> be >> "justifiable" to you) are: >> >> - Many security applications add a textual signature similar to >> "This >> mail was scanned by The Best Antivirus". > > Just to be clear, this approach has no security value unless they > also > actively filter *out* any and all content which might be rendered as > "This mail was scanned by The Best Antivirus". Otherwise, it's > trivial > for an attacker to include the string in their initial mail. > > And frankly, with HTML e-mail these days, i suspect it would be > rather > difficult to match all strings that might render to something > visually > indistinguishable from this. and difficult to excise them cleanly > without damaging other content. Once an antivirus starts actively > tampering with content, i think it's beyond its useful scope, > regardless > of the TLS implementations. Keep the communication channels > separate, > thanks. > >> - If something bad is detected in the traffic, the middlebox might >> want >> to issue an HTTP redirect, e.g. to display a copy of the company's >> security policy. > > Since HTTP redirects can only be done in an HTTP header, the > middlebox > would need to buffer all HTTP content before relaying it to the User > Agent, in case "bad" material was found at the end. > > I don't think either of these use cases are valuable, certainly not > valuable enough to warrant allowing middleboxes to violate the > integrity > guarantees of TLS. > > --dkg From chris@randomnonce.org Tue Aug 30 07:56:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA7421F8B47 for ; Tue, 30 Aug 2011 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAD65enaGU4R for ; Tue, 30 Aug 2011 07:56:55 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0561E21F8B4C for ; Tue, 30 Aug 2011 07:56:54 -0700 (PDT) Received: by qyk35 with SMTP id 35so4122199qyk.10 for ; Tue, 30 Aug 2011 07:58:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.77 with SMTP id kn13mr1808980qcb.105.1314716302434; Tue, 30 Aug 2011 07:58:22 -0700 (PDT) Received: by 10.229.190.211 with HTTP; Tue, 30 Aug 2011 07:58:22 -0700 (PDT) X-Originating-IP: [96.244.254.104] In-Reply-To: <036F4DE5-2E91-4946-87E2-F3258038E511@checkpoint.com> References: <20110825073046.30318.5618.idtracker@ietfa.amsl.com> <036F4DE5-2E91-4946-87E2-F3258038E511@checkpoint.com> Date: Tue, 30 Aug 2011 10:58:22 -0400 Message-ID: From: Chris Richardson To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org List" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 14:56:57 -0000 If the middlebox is inserting KeyShareInfo records into the stream, then it must modify the TCP sequence number on all future packets in the handshake. One cannot use a "dumb" middlebox that modifies the handshakes and nothing more. Perhaps an out-of-band keysharing mechanism would be better. On Thu, Aug 25, 2011 at 3:39 AM, Yoav Nir wrote: > Hi all > > Several weeks ago, Dave McGrew submitted a draft for improving the workin= gs of TLS proxies. As expected, this generated a lot of controversy, with s= ome people saying that they'd rather hand over the session keys to the midd= lebox than to standardize a MitM attack. > > I was on the other side of that debate, but one problem with comparing th= e two alternatives is that for proxies there are several commercial product= s and Dave's draft, while there's nothing for key sharing. To remedy that, = and help the discussion along, I've submitted the below draft. Comments and= additional controversy are very welcome. > > Yoav > > Begin forwarded message: > >> From: "internet-drafts@ietf.org" >> Date: August 25, 2011 10:30:46 AM GMT+03:00 >> To: "i-d-announce@ietf.org" >> Subject: I-D Action: draft-nir-tls-keyshare-00.txt >> Reply-To: "internet-drafts@ietf.org" >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : A Method for Sharing Record Prot= ocol Keys with a Middlebox in TLS >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Yoav Nir >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-nir-tls-keyshare-00.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-08-25 >> >> =A0 This document contains a straw man proposal for a method for sharing >> =A0 symmetric session keys between a TLS client and a middlebox, so that >> =A0 the middlebox can decrypt the TLS-protected traffic. >> >> =A0 This method is an alternative to the middlebox becoming a proxy. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nir-tls-keyshare-00.txt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ynir@checkpoint.com Wed Aug 31 04:56:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3054721F85B5 for ; Wed, 31 Aug 2011 04:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkpXb2fTcrTF for ; Wed, 31 Aug 2011 04:56:24 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2964821F85B1 for ; Wed, 31 Aug 2011 04:56:23 -0700 (PDT) X-CheckPoint: {4E5E2F06-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p7VBvqDV016479; Wed, 31 Aug 2011 14:57:52 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 31 Aug 2011 14:57:52 +0300 From: Yoav Nir To: Chris Richardson Date: Wed, 31 Aug 2011 14:57:51 +0300 Thread-Topic: [TLS] TLS and middleboxes again Thread-Index: Acxn1TV6EVX++21lQ/aT0oUSAkz7vw== Message-ID: <0AD45ACF-20DA-474B-BEB8-ECAF7AC2EBF3@checkpoint.com> References: <20110825073046.30318.5618.idtracker@ietfa.amsl.com> <036F4DE5-2E91-4946-87E2-F3258038E511@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org List" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 11:56:25 -0000 The middlebox would still have to at least delay application records until = the keys are delivered. Also, making sure that the keys are actually delive= red to the middlebox reliably is extremely hard unless we use the existing = connection.=20 I just don't see an out-of-band delivery as being workable. If we could eliminate the records that the middlebox inserts, and have only= the client and server send records, I agree that it would be better, but w= ithout the middlebox announcing its presence, I don't see how the protocol = could work without too much key sharing. I'll be glad to get some suggestio= ns. Yoav On Aug 30, 2011, at 5:58 PM, Chris Richardson wrote: > If the middlebox is inserting KeyShareInfo records into the stream, > then it must modify the TCP sequence number on all future packets in > the handshake. One cannot use a "dumb" middlebox that modifies the > handshakes and nothing more. >=20 > Perhaps an out-of-band keysharing mechanism would be better. >=20 > On Thu, Aug 25, 2011 at 3:39 AM, Yoav Nir wrote: >> Hi all >>=20 >> Several weeks ago, Dave McGrew submitted a draft for improving the worki= ngs of TLS proxies. As expected, this generated a lot of controversy, with = some people saying that they'd rather hand over the session keys to the mid= dlebox than to standardize a MitM attack. >>=20 >> I was on the other side of that debate, but one problem with comparing t= he two alternatives is that for proxies there are several commercial produc= ts and Dave's draft, while there's nothing for key sharing. To remedy that,= and help the discussion along, I've submitted the below draft. Comments an= d additional controversy are very welcome. >>=20 >> Yoav >>=20 From yaronf.ietf@gmail.com Wed Aug 31 12:37:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC17B21F8F57 for ; Wed, 31 Aug 2011 12:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.505 X-Spam-Level: X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxEbJPMXPl8y for ; Wed, 31 Aug 2011 12:37:44 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB5A521F8F35 for ; Wed, 31 Aug 2011 12:37:43 -0700 (PDT) Received: by ewy19 with SMTP id 19so746097ewy.31 for ; Wed, 31 Aug 2011 12:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Y8Q3PX26Cc4rfCWayucIBYFSx2jkLBmmH8ubXcoeivY=; b=SUY/tW58cPBFYZarQgxNEAO7B96hZlVbWoRJmZyQodlDGDM1u7eGyOq9P5/mjibrx5 IUfSyRRehqQFsuXpz/dtAathGZc113tq0XwLS08mxGIdEtg8WfPoQO3Oz5w03XfrTDbG YXdAt7bkya0ZIpOyVUzrn9CnOYvQUTBVQeXRw= Received: by 10.213.108.131 with SMTP id f3mr487677ebp.16.1314819553958; Wed, 31 Aug 2011 12:39:13 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-242-252.red.bezeqint.net [79.181.242.252]) by mx.google.com with ESMTPS id 35sm4978830eex.15.2011.08.31.12.39.11 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 12:39:13 -0700 (PDT) Message-ID: <4E5E8DD9.40604@gmail.com> Date: Wed, 31 Aug 2011 22:39:05 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:37:44 -0000 Here's a suggestion to avoid the records that announce the proxy. It's not ideal, but it may be easier to implement/deploy than an intrusive proxy. We could use some sort of discovery mechanism to detect the presence of the proxy. Then the client queries the proxy for its certificate hash (with a well known URL), and you can assume the proxy will in fact be there. The discovery process itself is *not* security-sensitive, and we can use caching. Two options are PAC (http://en.wikipedia.org/wiki/Proxy_auto-config and http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) and DNS SRV records. The former is commonly deployed in enterprises, the latter is much simpler to standardize and implement, and architecturally cleaner. Thanks, Yaron On 31.8.2011 22:00, tls-request@ietf.org wrote: > Date: Wed, 31 Aug 2011 14:57:51 +0300 > From: Yoav Nir > To: Chris Richardson > Cc: "tls@ietf.org List" > Subject: Re: [TLS] TLS and middleboxes again > Message-ID:<0AD45ACF-20DA-474B-BEB8-ECAF7AC2EBF3@checkpoint.com> > Content-Type: text/plain; charset="us-ascii" > > The middlebox would still have to at least delay application records until the keys are delivered. Also, making sure that the keys are actually delivered to the middlebox reliably is extremely hard unless we use the existing connection. > > I just don't see an out-of-band delivery as being workable. > > If we could eliminate the records that the middlebox inserts, and have only the client and server send records, I agree that it would be better, but without the middlebox announcing its presence, I don't see how the protocol could work without too much key sharing. I'll be glad to get some suggestions. > > Yoav > > On Aug 30, 2011, at 5:58 PM, Chris Richardson wrote: > >> If the middlebox is inserting KeyShareInfo records into the stream, >> then it must modify the TCP sequence number on all future packets in >> the handshake. One cannot use a "dumb" middlebox that modifies the >> handshakes and nothing more. >> >> Perhaps an out-of-band keysharing mechanism would be better. >> >> On Thu, Aug 25, 2011 at 3:39 AM, Yoav Nir wrote: >>> Hi all >>> >>> Several weeks ago, Dave McGrew submitted a draft for improving the workings of TLS proxies. As expected, this generated a lot of controversy, with some people saying that they'd rather hand over the session keys to the middlebox than to standardize a MitM attack. >>> >>> I was on the other side of that debate, but one problem with comparing the two alternatives is that for proxies there are several commercial products and Dave's draft, while there's nothing for key sharing. To remedy that, and help the discussion along, I've submitted the below draft. Comments and additional controversy are very welcome. >>> >>> Yoav >>> > > > ------------------------------ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > End of TLS Digest, Vol 85, Issue 22 > *********************************** From ekr@rtfm.com Wed Aug 31 17:50:00 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B45521F8CEE for ; Wed, 31 Aug 2011 17:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VudqIQKcpnmy for ; Wed, 31 Aug 2011 17:49:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8544321F8CE8 for ; Wed, 31 Aug 2011 17:49:59 -0700 (PDT) Received: by wwf5 with SMTP id 5so912896wwf.13 for ; Wed, 31 Aug 2011 17:51:30 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr994794wby.18.1314838290328; Wed, 31 Aug 2011 17:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.3.5 with HTTP; Wed, 31 Aug 2011 17:51:10 -0700 (PDT) From: Eric Rescorla Date: Wed, 31 Aug 2011 17:51:10 -0700 Message-ID: To: draft-ietf-dtls-heartbeat@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:50:00 -0000 S 1.1. "and their adoptions" -> "and their adaptations" "as described" -> described S 3. "Like the ChangeCipherSpec message,.... can arrive at any time" I guess a CSS can in principle arrive at any time, but it's not permitted at any time. You couldn't send it as the first message of a connection, for instance. I'm not sure there is a specific statement to this effect in 5246, but it seems implicit in S 7.3. "MUST stop the retransmission timer" -> "MUST stop the DTLS retransmission timer" perhaps? "HeartbeatRequest messages from older epochs must be discarded" I would clarify that this is DTLS only since TLS has no epochs. S 4. You should probably clarify why the padding length is what it is. S 5.1 We'll need to update the 4347 citation to DTLS 1.2 5.2. "allows this check" -> "allows a check" perhaps? "multiple round trip times" You should probably recommend some multiple. S 6. Specification required is a pretty low bar for a field this small... Perhaos Expert Review would be better. -Ekr From ynir@checkpoint.com Wed Aug 31 23:05:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55D21F8B31 for ; Wed, 31 Aug 2011 23:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVwRmu8CMNm4 for ; Wed, 31 Aug 2011 23:05:51 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85021F8B30 for ; Wed, 31 Aug 2011 23:05:50 -0700 (PDT) X-CheckPoint: {4E5F2E5C-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p8167I8q005106; Thu, 1 Sep 2011 09:07:18 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 1 Sep 2011 09:07:19 +0300 From: Yoav Nir To: Yaron Sheffer Date: Thu, 1 Sep 2011 09:07:16 +0300 Thread-Topic: [TLS] TLS and middleboxes again Thread-Index: AcxobWdh53mKB7EGSSiKsUveMyP/7A== Message-ID: <395BFC9B-5B8C-431A-A09A-922C1C088422@checkpoint.com> References: <4E5E8DD9.40604@gmail.com> In-Reply-To: <4E5E8DD9.40604@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS and middleboxes again X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 06:05:51 -0000 On Aug 31, 2011, at 10:39 PM, Yaron Sheffer wrote: > Here's a suggestion to avoid the records that announce the proxy. It's=20 > not ideal, but it may be easier to implement/deploy than an intrusive pro= xy. >=20 > We could use some sort of discovery mechanism to detect the presence of=20 > the proxy. Then the client queries the proxy for its certificate hash=20 > (with a well known URL), and you can assume the proxy will in fact be=20 > there. The discovery process itself is *not* security-sensitive, and we=20 > can use caching. >=20 > Two options are PAC (http://en.wikipedia.org/wiki/Proxy_auto-config and=20 > http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) and DNS=20 > SRV records. The former is commonly deployed in enterprises, the latter=20 > is much simpler to standardize and implement, and architecturally cleaner= . >=20 All these involve a potentially lengthy discovery process, and more inter-l= ayer communications than I'd like.=20 The common use case for a middlebox is for when I'm "inside" the company pe= rimeter. In the place where I work, there's WLAN reception on all floors, b= ut none in the stairwell. Going upstairs with a smartphone involves roaming= from the WLAN to the 3G network and back to the WLAN. As far as the middle= box is concerned, you're going from "inside" to "outside" and back "inside"= . There is an obvious way for discovery: the client sends hashes of the middl= ebox certificates in the extension. If the middlebox hash is missing, the m= iddlebox will interfere by sending an alert with its hash and a URL for get= ting its certificate. The harder question is how to discover that the proxy= is gone (or rather, off-path). It's not quite as important, because sendin= g encrypted keys to a non-existant middlebox should not cause a lot of dama= ge, but we don't want to keep accumulating middleboxes.