From stephen.farrell@cs.tcd.ie Fri Jun 1 15:38:53 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A282F11E8111 for ; Fri, 1 Jun 2012 15:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 dHCfpp+TmPeg for ; Fri, 1 Jun 2012 15:38:52 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 73B7511E809A for ; Fri, 1 Jun 2012 15:38:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DA696154507 for ; Fri, 1 Jun 2012 23:38:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338590331; bh=x8Y9w0e/EXp2cy WW/ZBiRS7AUPVCXf7eGOyNxNSLd9k=; b=eoVeWeABBNEhetHbPQXkNHbZQ7Zbsc 4HD32bQKZn0S9KZnQ7f8AgXX/efBR6DmbZX3oaqR4ciKZ8roz9UVx7ol5gjl++Fj RIKfm4EFK1dW30caSYSij7I09wTtCScvJxjhTLf9vOD2cBPBb6CeaURBr+2Hr7RP 6G5/XaU4PZ0x3wFu6yrNElqb1DdX/iD3pxaJ62QmZh/RWxrhpYgwiXCUQEU5Sicn gfpktlXQ8MQr6MY1bunu9CuFaNFMH2M56iw2ICxJUOQxDYnJYeN5NjO59dXLPm9M 8atutvGfNpT6Lq7jad8Qp+U9efjKl1DU6uneUSDtDYKm3uG0rXOVs8OA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id GYfwQSDw5n9t for ; Fri, 1 Jun 2012 23:38:51 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.68.37]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 23DF41544D7 for ; Fri, 1 Jun 2012 23:38:51 +0100 (IST) Message-ID: <4FC9447A.1070606@cs.tcd.ie> Date: Fri, 01 Jun 2012 23:38:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "saag@ietf.org" References: <902B0DD9-4AFA-45F5-B4C7-94462B1FEAF7@oasis-open.org> In-Reply-To: <902B0DD9-4AFA-45F5-B4C7-94462B1FEAF7@oasis-open.org> X-Enigmail-Version: 1.4.1 X-Forwarded-Message-Id: <902B0DD9-4AFA-45F5-B4C7-94462B1FEAF7@oasis-open.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: 15-day Public Reviews for KMIP V1.1 Committee Specification and Note drafts X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 22:38:53 -0000 Just got this. I guess if you care, comment there. S -------- Original Message -------- Subject: 15-day Public Reviews for KMIP V1.1 Committee Specification and Note drafts Date: Fri, 1 Jun 2012 18:37:30 -0400 From: Chet Ensign To: tc-announce@lists.oasis-open.org, members@lists.oasis-open.org, kmip@lists.oasis-open.org The OASIS Key Management Interoperability Protocol (KMIP) TC [1] members have recently approved two Committee Specification Drafts (CSD) and two Committee Note Drafts (CND) and submitted these drafts for 15-day public review: Key Management Interoperability Protocol Specification Version 1.1 Committee Specification Draft 02 / Public Review Draft 02 14 May 2012 Key Management Interoperability Protocol Profiles Version 1.1 Committee Specification Draft 02 / Public Review Draft 02 14 May 2012 Key Management Interoperability Protocol Usage Guide Version 1.1 Committee Note Draft 02 / Public Review Draft 02 14 May 2012 Key Management Interoperability Protocol Test Cases Version 1.1 Committee Note Draft 02 / Public Review Draft 02 14 May 2012 Specification Overview: The KMIP Specification V1.1 CSPRD02 is the normative description of objects, operations and attributes for this version of the OASIS Key Management Interoperability Protocol. The KMIP Profile V1.1 CSPRD02 is the normative description of conformance profiles for this version of the OASIS Key Management Interoperability Protocol. The KMIP Usage Guide V1.1 CSD.02 provides illustrative information regarding the implementation of solutions using the objects, operations and attributes for this version of the OASIS Key Management Interoperability Protocol. The KMIP Test Cases V1.1 CSD.02 is the illustrative description of test cases for objects, operations and attributes for this version of the OASIS Key Management Interoperability Protocol. TC Description: The OASIS KMIP TC works to define a single, comprehensive protocol for communication between encryption systems and a broad range of new and legacy enterprise applications, including email, databases, and storage devices. By removing redundant, incompatible key management processes, KMIP will provide better data security while at the same time reducing expenditures on multiple products. Public Review Period: The public review starts 4 June 2012 and ends 19 June 2012. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. URIs: The complete packages of the prose specification and note documents and related files are available in the ZIP distribution file at: Key Management Interoperability Protocol Specification Version 1.1 http://www.oasis-open.org/committees/download.php/46154/kmip-spec-v1.1-csprd02.zip Key Management Interoperability Protocol Profiles Version 1.1 http://www.oasis-open.org/committees/download.php/46155/kmip-profiles-v1.1-csprd02.zip Key Management Interoperability Protocol Usage Guide Version 1.1 http://www.oasis-open.org/committees/download.php/46157/kmip-ug-v1.1-cnprd02.zip Key Management Interoperability Protocol Test Cases Version 1.1 http://www.oasis-open.org/committees/download.php/46156/kmip-testcases-v1.1-cnprd02.zip The resolution log for comments received in the prior public review announced 22 January 2012 is available at: http://www.oasis-open.org/committees/download.php/46158/KMIP-TC-Public-Review-Comments-22mar2012-.xls Additional information about the specification and the OASIS Key Management Interoperability Protocol (KMIP) TC may be found at the TC's public home page: https://www.oasis-open.org/committees/kmip/ Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button labeled "Send A Comment" at the top of the TC public home, or directly at: https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=kmip Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at: http://lists.oasis-open.org/archives/kmip-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of KMIP V1.1 Committee Specification and Note drafts, we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. ========== Additional references: [1] OASIS Key Management Interoperability Protocol (KMIP) TC https://www.oasis-open.org/committees/kmip/ [2] http://www.oasis-open.org/who/intellectualproperty.php [3] http://www.oasis-open.org/committees/kmip/ipr.php RF on RAND Mode https://www.oasis-open.org/policies-guidelines/ipr#s10.2.2 /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 From turners@ieca.com Tue Jun 5 12:55:32 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDF521F85B1 for ; Tue, 5 Jun 2012 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 BwHaEhXnvn2e for ; Tue, 5 Jun 2012 12:55:31 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.38.21]) by ietfa.amsl.com (Postfix) with ESMTP id 502F921F85AF for ; Tue, 5 Jun 2012 12:55:31 -0700 (PDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id AF61B7B8C2E60 for ; Tue, 5 Jun 2012 14:55:30 -0500 (CDT) Received: from [71.191.2.244] (port=36493 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sbzqk-0003q7-GU for saag@ietf.org; Tue, 05 Jun 2012 14:55:30 -0500 Message-ID: <4FCE6431.6050808@ieca.com> Date: Tue, 05 Jun 2012 15:55:29 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.2.244]:36493 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 19:55:32 -0000 All, There are many proposals for how to say which key or certificate or trust anchor should be used by the client in a TLS session that it is about to open. These proposals include making that decision in the DNS (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information. Similarly, there are also proposals on how to say whether or not a client should expect to see a particular service running under TLS. These proposals include making that indication in the DNS (draft hoffman-server-has-tls, expired but might be revived) and in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport sec/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information. Is a standards-track operations statement needed to describe the choices that a TLS server administrator has, and to deal with conflicts between the proposals? spt From hotz@jpl.nasa.gov Tue Jun 5 13:16:32 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C364521F8775 for ; Tue, 5 Jun 2012 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OkeF4TvqhKB for ; Tue, 5 Jun 2012 13:16:32 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 5573621F875A for ; Tue, 5 Jun 2012 13:16:32 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q55KGTDn030440 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 5 Jun 2012 13:16:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4FCE6431.6050808@ieca.com> Date: Tue, 5 Jun 2012 13:16:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33D30C0D-5399-43BE-9113-D50AA25DAB62@jpl.nasa.gov> References: <4FCE6431.6050808@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: saag@ietf.org Subject: Re: [saag] Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 20:16:32 -0000 On Jun 5, 2012, at 12:55 PM, Sean Turner wrote: > Is a standards-track operations statement needed to describe the = choices that a TLS server administrator has, and to deal with conflicts = between the proposals? IMO, ultimately, absolutely. I doubt we have sufficient understanding = and consensus to do it yet (but I hope I'm wrong). ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From ynir@checkpoint.com Tue Jun 5 14:46:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2139621F8779 for ; Tue, 5 Jun 2012 14:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 i3gia-eP2Gfw for ; Tue, 5 Jun 2012 14:46:22 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8B82021F8775 for ; Tue, 5 Jun 2012 14:46:20 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q55LkJrE009768 for ; Wed, 6 Jun 2012 00:46:19 +0300 X-CheckPoint: {4FCE8A24-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jun 2012 00:46:18 +0300 From: Yoav Nir To: "saag@ietf.org" Date: Wed, 6 Jun 2012 00:46:14 +0300 Thread-Topic: [websec] Pinning Thread-Index: Ac1DZKLe9GWj8p+ZQvGqNZ9OUEal+g== Message-ID: <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.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 x-cpdlp: 118f82a43ade27cbe23c720ea4af59ae5edf178aa4 Content-Type: multipart/alternative; boundary="_000_8E52CEC54FEB4464AB1121F1B9208C5Ccheckpointcom_" MIME-Version: 1.0 Subject: [saag] Fwd: [websec] Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 21:46:23 -0000 --_000_8E52CEC54FEB4464AB1121F1B9208C5Ccheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At Paul's request, forwarding to SAAG. Begin forwarded message: From: Yoav Nir > Subject: Re: [websec] Pinning Date: June 6, 2012 12:11:37 AM GMT+03:00 To: IETF WebSec WG > Hi The similarity of pinning and DANE has been discussed before. DANE relies o= n DNSSEC being deployed, which key-pinning does not. Come to think of it, t= he draft needs a section comparing with DANE, but that's for another thread= . draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Inst= ead of the pins getting attested to in HTTP headers, you have a special pub= lic/private key pair, that you use to sign the SPKI from the server certifi= cate within the a TLS extension. Like key-pinning there's a TOFU element he= re, because the client only learns about the special key when it encounters= it in a TLS handshake. The obvious question is why would we need both key-pinning and tack. It has= been asked on the TLS mailing list: http://www.ietf.org/mail-archive/web/tls/current/msg08818.html An answer by the draft authors is here: http://www.ietf.org/mail-archive/web/tls/current/msg08830.html In the grand scheme of things, it's not good for the IETF to make >1 standa= rds, both of which need to be implemented in both servers and browsers, tha= t accomplish the same thing, and Sean is correct that implementing more tha= n one may lead to mismatching information. In a sense DANE is also doing th= e same thing, but DANE requires DNSSEC everywhere, so it's operational prof= ile is different. But Tack and cert pinning both have no prerequisites and = accomplish the same thing, so what if one's at the HTTP layer, while the ot= her is at the TLS layer. I don't think the TLS WG is very excited about TACK (see the mailing list) = but regardless, I think it's up to us to look at both options and decide if= we would like to go on with cert-pinning, or whether we thing TACK is bett= er. Yoav On Jun 5, 2012, at 11:47 PM, Paul Hoffman wrote: >From the SAAG mailing list, but appropriate here. I bet that Sean would app= reciate all discussion to go on on the SAAG mailing list... Begin forwarded message: From: Sean Turner Subject: [saag] Pinning Date: June 5, 2012 12:55:29 PM PDT To: saag@ietf.org All, There are many proposals for how to say which key or certificate or trust a= nchor should be used by the client in a TLS session that it is about to ope= n. These proposals include making that decision in the DNS (https://datatra= cker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after TLS = has happened once, to be remembered in the future (https://datatracker.ietf= .org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (https:/= /datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of thes= e protocols are deployed, operational mistakes could lead to a client getti= ng conflicting information. Similarly, there are also proposals on how to say whether or not a client s= hould expect to see a particular service running under TLS. These proposals= include making that indication in the DNS (draft hoffman-server-has-tls, e= xpired but might be revived) and in the application after TLS has happened = once, to be remembered in the future (https://datatracker.ietf.org/doc/draf= t-ietf-websec-strict-transport sec/). If more than one of these protocols a= re deployed, operational mistakes could lead to a client getting conflictin= g information. Is a standards-track operations statement needed to describe the choices th= at a TLS server administrator has, and to deal with conflicts between the p= roposals? spt _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec Scanned by Check Point Total Security Gateway. --_000_8E52CEC54FEB4464AB1121F1B9208C5Ccheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At Paul's request, forward= ing to SAAG.

Begin forwarded message:

= From: Yoav Nir <ynir@checkpoint.com= >
Subject: Re: [websec] Pin= ning
Date: June 6, 2012 12:11:37 = AM GMT+03:00
To: IETF WebSec WG <<= a href=3D"mailto:websec@ietf.org">websec@ietf.org>
<= br>
Hi

The similarity of pinning and DANE has been discussed bef= ore. DANE relies on DNSSEC being deployed, which key-pinning does not. Come= to think of it, the draft needs a section comparing with DANE, but that's = for another thread.

draft-perrin-tls-tack seems to tackle the same p= roblem as key-pinning. Instead of the pins getting attested to in HTTP head= ers, you have a special public/private key pair, that you use to sign the S= PKI from the server certificate within the a TLS extension. Like key-pinnin= g there's a TOFU element here, because the client only learns about the spe= cial key when it encounters it in a TLS handshake.

The obvious quest= ion is why would we need both key-pinning and tack. It has been asked on th= e TLS mailing list:
http://www.ietf.org/mail-archive/web/tls/current/ms= g08818.html

An answer by the draft authors is here:
http://ww= w.ietf.org/mail-archive/web/tls/current/msg08830.html

In the grand s= cheme of things, it's not good for the IETF to make >1 standards, both o= f which need to be implemented in both servers and browsers, that accomplis= h the same thing, and Sean is correct that implementing more than one may l= ead to mismatching information. In a sense DANE is also doing the same thin= g, but DANE requires DNSSEC everywhere, so it's operational profile is diff= erent. But Tack and cert pinning both have no prerequisites and accomplish = the same thing, so what if one's at the HTTP layer, while the other is at t= he TLS layer.

I don't think the TLS WG is very excited about TACK (s= ee the mailing list) but regardless, I think it's up to us to look at both = options and decide if we would like to go on with cert-pinning, or whether = we thing TACK is better.

Yoav

On Jun 5, 2012, at 11:47 PM, Pa= ul Hoffman wrote:

From the SAAG mailing li= st, but appropriate here. I bet that Sean would appreciate all discussion t= o go on on the SAAG mailing list...

Begin forwarded message:
<= /blockquote>

From: Sean Turner <turners@ieca.com><= br>
Subject: [saag] Pinning
Date: June 5, 2012 12:55:29 PM PDT
<= /blockquote>
To: saag@ietf.org
=

All,

<= blockquote type=3D"cite">
There are many proposals= for how to say which key or certificate or trust anchor should be used by = the client in a TLS session that it is about to open. These proposals inclu= de making that decision in the DNS (https://datatracker.ietf.org/doc/draft-= ietf-dane-protocol/), in the application after TLS has happened once, to be= remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-webs= ec-key-pinning/), and in the TLS handshake (https://datatracker.ietf.org/do= c/draft-perrin tls-tack/). If more than one of these protocols are deployed= , operational mistakes could lead to a client getting conflicting informati= on.

Similarly, there are also proposals on how to say whether = or not a client should expect to see a particular service running under TLS= . These proposals include making that indication in the DNS (draft hoffman-= server-has-tls, expired but might be revived) and in the application after = TLS has happened once, to be remembered in the future (https://datatracker.= ietf.org/doc/draft-ietf-websec-strict-transport sec/). If more than one of = these protocols are deployed, operational mistakes could lead to a client g= etting conflicting information.

Is a standards-track operation= s statement needed to describe the choices that a TLS server administrator = has, and to deal with conflicts between the proposals?

spt
=

_____________________________________________= __
websec mailing list
websec@ietf.org
https://www.ietf.org/mailma= n/listinfo/websec

Scanned by Check Point Total Security Gateway.
=

= --_000_8E52CEC54FEB4464AB1121F1B9208C5Ccheckpointcom_-- From paul.hoffman@vpnc.org Tue Jun 5 15:01:19 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A0D21F86B7 for ; Tue, 5 Jun 2012 15:01:19 -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=[AWL=0.000, 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 VLayaU-+T28O for ; Tue, 5 Jun 2012 15:01:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4521F86A1 for ; Tue, 5 Jun 2012 15:01:18 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q55M18FV053760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Jun 2012 15:01:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> Date: Tue, 5 Jun 2012 15:01:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1278) Cc: "saag@ietf.org" Subject: Re: [saag] [websec] Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 22:01:19 -0000 On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote: >> The similarity of pinning and DANE has been discussed before. DANE = relies on DNSSEC being deployed, which key-pinning does not. Correct. Further, key-pinning in HTTP only applies to HTTP and relies on = the client being able to establish a TLS session using non-key-pinning = semantics. Key-pinning in TLS relies works with any lower-layer protocol = and relies on the client being able to establish a TLS session using = non-key-pinning semantics. >> Come to think of it, the draft needs a section comparing with DANE, = but that's for another thread. >>=20 >> draft-perrin-tls-tack seems to tackle the same problem as = key-pinning. Instead of the pins getting attested to in HTTP headers, = you have a special public/private key pair, that you use to sign the = SPKI from the server certificate within the a TLS extension. Like = key-pinning there's a TOFU element here, because the client only learns = about the special key when it encounters it in a TLS handshake. >>=20 >> The obvious question is why would we need both key-pinning and tack. It would be clearer if you said "both key-pinning in HTTP and = key-pinning in TLS (tack)". --Paul Hoffman From smb@cs.columbia.edu Tue Jun 5 19:41:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFA121F865F for ; Tue, 5 Jun 2012 19:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQGUYXRRa3f3 for ; Tue, 5 Jun 2012 19:41:20 -0700 (PDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by ietfa.amsl.com (Postfix) with ESMTP id 65DA321F865B for ; Tue, 5 Jun 2012 19:41:20 -0700 (PDT) Received: from [10.9.0.230] (fireball.cs.columbia.edu [128.59.13.10]) (user=smb2132 mech=PLAIN bits=0) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q562fDjr028465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2012 22:41:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <4FCE6431.6050808@ieca.com> Date: Tue, 5 Jun 2012 22:41:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCE6431.6050808@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1278) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: saag@ietf.org Subject: Re: [saag] Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 02:41:21 -0000 On Jun 5, 2012, at 3:55 PM, Sean Turner wrote: > All, >=20 > There are many proposals for how to say which key or certificate or = trust anchor should be used by the client in a TLS session that it is = about to open. These proposals include making that decision in the DNS = (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and = in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin = tls-tack/). If more than one of these protocols are deployed, = operational mistakes could lead to a client getting conflicting = information. >=20 > Similarly, there are also proposals on how to say whether or not a = client should expect to see a particular service running under TLS. = These proposals include making that indication in the DNS (draft = hoffman-server-has-tls, expired but might be revived) and in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport = sec/). If more than one of these protocols are deployed, operational = mistakes could lead to a client getting conflicting information. >=20 > Is a standards-track operations statement needed to describe the = choices that a TLS server administrator has, and to deal with conflicts = between the proposals? It strikes me more as BCP material. If there are multiple standards, what's needed is advice on how to choose amongst them, rather than a standards track document that says "ignore these other standards track RFCs and use this other one instead." --Steve Bellovin, https://www.cs.columbia.edu/~smb From lear@cisco.com Wed Jun 6 02:27:25 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3537321F868A; Wed, 6 Jun 2012 02:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 FJ5QM0TGHvP6; Wed, 6 Jun 2012 02:27:24 -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 A161721F858E; Wed, 6 Jun 2012 02:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=7591; q=dns/txt; s=iport; t=1338974843; x=1340184443; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZF4sQJhbnX9S5wByBTpE9Z34i9WZ6Uy3vu+YMzdFpCE=; b=j65UT51RsYn93djaBJtUNBLpDqGt0SxNANLjZk9xqfjN6lHr5d7mNrPC 1qPJ1CwGb//qew6J7BG2+qiSaE/hh8kHMktOOScT5NEt9V+zOtAiQUUx2 cjuPRGX5oW2WcbCgZx8YGvJ0yiuUFmD0hPyjucTt/1U7cfBozaP+C81cM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACUiz0+Q/khM/2dsb2JhbABFDoVArmKBB4IYAQEBBBIBEFUBEAkCGAkWCwICCQMCAQIBRQYNAQUCAQEFGYdpC5ckjRaSZYsUhQeBEgOVHI4SgWaCJzs X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208,217";a="139198384" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2012 09:27:14 +0000 Received: from dhcp-10-55-81-197.cisco.com (dhcp-10-55-81-197.cisco.com [10.55.81.197]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q569RDCK020222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 09:27:14 GMT Message-ID: <4FCF2271.6090705@cisco.com> Date: Wed, 06 Jun 2012 11:27:13 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> In-Reply-To: <4FCD4E0F.2080100@isi.edu> X-Enigmail-Version: 1.4.1 Content-Type: multipart/alternative; boundary="------------050206090500040305030108" Cc: tsvwg@ietf.org, "saag@ietf.org" Subject: Re: [saag] [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:27:25 -0000 This is a multi-part message in MIME format. --------------050206090500040305030108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Joe, I support the development of this draft, and would be willing to provide you with both content and editorial assistance. I would ask that (at least) one additional important question be considered by this group and the security area: * Is a request for a static port assignment in order to accommodate firewalls still an appropriate reason? I ask this question because there have been applications for as many as six ports for related or very similar services that could all be dynamically discovered from one. Some come back and say that they are concerned that firewalls will prevent the service from functioning properly. What is the IETF's point of view on this? Eliot On 6/5/12 2:08 AM, Joe Touch wrote: > Hi, all, > > I've resubmitted this as a WG doc. The major changes were to include > full references for previous placeholders and a few minor notes. > > It would be useful to get feedback on whether there are any areas that > should be addressed that are not listed before diving into the two key > issues I hope we can discuss as part of this doc: > > - whether to deprecate the distinction between system and > user ports (or to do nothing at this time) > > - whether to make stronger recommendations on the use of > security on port services (i.e., whether security "should" > be supported for new services, or to make no specific > recommendation at this time) > > Any gap material notes would be most useful now, though. > > Joe > > On 5/31/2012 11:34 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Transport Area Working >> Group Working Group of the IETF. >> >> Title : Recommendations for Transport Port Uses >> Author(s) : Joe Touch >> Filename : draft-ietf-tsvwg-port-use-00.txt >> Pages : 11 >> Date : 2012-05-30 >> >> This document provides recommendations to application and service >> designers on how to use the transport protocol port number space to >> help in its preservation. **NOTE THAT THIS CURRENT VERSION IS >> LARGELY AN OUTLINE OF ISSUES**. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ >> > > --------------050206090500040305030108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Joe,

I support the development of this draft, and would be willing to provide you with both content and editorial assistance.  I would ask that (at least) one additional important question be considered by this group and the security area:
  • Is a request for a static port assignment in order to accommodate firewalls still an appropriate reason?

I ask this question because there have been applications for as many as six ports for related or very similar services that could all be dynamically discovered from one.  Some come back and say that they are concerned that firewalls will prevent the service from functioning properly.  What is the IETF's point of view on this?

Eliot

On 6/5/12 2:08 AM, Joe Touch wrote:
Hi, all,

I've resubmitted this as a WG doc. The major changes were to include full references for previous placeholders and a few minor notes.

It would be useful to get feedback on whether there are any areas that should be addressed that are not listed before diving into the two key issues I hope we can discuss as part of this doc:

    - whether to deprecate the distinction between system and
    user ports (or to do nothing at this time)

    - whether to make stronger recommendations on the use of
    security on port services (i.e., whether security "should"
    be supported for new services, or to make no specific
    recommendation at this time)

Any gap material notes would be most useful now, though.

Joe

On 5/31/2012 11:34 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF.

    Title           : Recommendations for Transport Port Uses
    Author(s)       : Joe Touch
    Filename        : draft-ietf-tsvwg-port-use-00.txt
    Pages           : 11
    Date            : 2012-05-30

    This document provides recommendations to application and service
    designers on how to use the transport protocol port number space to
    help in its preservation. **NOTE THAT THIS CURRENT VERSION IS
    LARGELY AN OUTLINE OF ISSUES**.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/



--------------050206090500040305030108-- From n.mavrogiannopoulos@gmail.com Wed Jun 6 05:17:19 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FED21F886B for ; Wed, 6 Jun 2012 05:17:19 -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 pgDBSYRVOQqC for ; Wed, 6 Jun 2012 05:17:19 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0856021F883F for ; Wed, 6 Jun 2012 05:17:18 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5406666ggn.31 for ; Wed, 06 Jun 2012 05:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=P5YluU2pZ8Bj/6zs2fMAuGZRc8juJiFP6sBbv8Xd40s=; b=lxGtNai6D8HMjRWMMV+KfXK4aLp1Ax74h/Rl2wxtyQbH23sKqWRml0qwRuObZNinsB jwbBMYtAv68a+cAw5b6g62J3jzTavgSWig3tiZQmrDhtf5EPRRtT4awuQyEEAHoxzBTk 8x5Ul8Z37Hi0AfxJ6p+HwOM8f52+ISiCqgi4IEqL/NfCg/2Ci5BtvxVix6OiUuj+orSq DNvTTVNOR6Q4pQ+zxC7T22z45cLBRYcKnxT0crqk/WTUlXDgtB/RyozlCkisRqI+zsur f/DFT/DmDmqJ/vqgSFQsOXGPRpPs6+AwthsIhxzNygExyTOLRzCFaEwbhhHwqhbCvYmw ERtQ== MIME-Version: 1.0 Received: by 10.42.12.83 with SMTP id x19mr13376917icx.16.1338985038439; Wed, 06 Jun 2012 05:17:18 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.231.80.15 with HTTP; Wed, 6 Jun 2012 05:17:18 -0700 (PDT) In-Reply-To: References: <4FCE6431.6050808@ieca.com> Date: Wed, 6 Jun 2012 14:17:18 +0200 X-Google-Sender-Auth: 4hA1gNgllLjckzqoqpXLWNAgyXU Message-ID: From: Nikos Mavrogiannopoulos To: saag@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [saag] [TLS] Fwd: Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 12:17:19 -0000 On Tue, Jun 5, 2012 at 11:17 PM, Paul Hoffman wrote= : > From the SAAG mailing list, but appropriate here. I bet that Sean would a= ppreciate all discussion to go on on the SAAG mailing list... > Begin forwarded message: >> From: Sean Turner >> Subject: [saag] Pinning >> There are many proposals for how to say which key or certificate or trus= t anchor should be used by the client in a TLS session that it is about to = open. These proposals include making that decision in the DNS (https://data= tracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after T= LS has happened once, to be remembered in the future (https://datatracker.i= etf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (http= s://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of t= hese protocols are deployed, operational mistakes could lead to a client ge= tting conflicting information. The fact that more than one protocols can be deployed is an advantage. In that case an attacker needs to control more infrastructure in order to perform an attack on a TLS session. If you compare to the current situation where the attacker only needs to control a random CA, it looks like an improvement. Of course the situation can be improved by restricting to few of these approaches rather than all (more peer verification paths is better, but also increases the probability of something going wrong unintentionally and thus false alarms). regards, Nikos From tobias.gondrom@gondrom.org Wed Jun 6 09:46:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636B321F86BB for ; Wed, 6 Jun 2012 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 j+EpKt+xFZ6H for ; Wed, 6 Jun 2012 09:46:12 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 396FE21F86A3 for ; Wed, 6 Jun 2012 09:46:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=cnxEZrk3HfqFHoJsXYYRgtdHcSxkG+7/7vZ35VgtazUVPdxd7RofFS3pgZMnCTHfT1IIW+LfkdgOmbp0rAA4w9OaAsTunL/Uyps2Vc3Gy8t68WqWe1nd6NP6Cllkf2sc; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 3983 invoked from network); 6 Jun 2012 18:46:04 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Jun 2012 18:46:04 +0200 Message-ID: <4FCF894B.8080002@gondrom.org> Date: Wed, 06 Jun 2012 17:46:03 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: paul.hoffman@vpnc.org, ynir@checkpoint.com, turners@ieca.com References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> In-Reply-To: <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org, saag@ietf.org Subject: Re: [saag] [websec] Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 16:46:13 -0000 Sean et al., I agree with Paul and Yoav and think the coordination between dane and websec on HSTS and key-pinning is ok. Both WGs are aware of potential coordination issues when mechanisms in both (DNSSEC and HTTP header) will be implemented eventually. I don't think we need an operations statement yet. Maybe at some point in the future an informational Best Practice or if you wish a Std Track can help. With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning, I am not so sure about potential conflicts here and whether we need or want both. Best regards, Tobias Ps.: And on a personal note, one thing I am not so happy about is that I can see from the tls-tack draft, that the authors are aware of key-pinning (which is nice) and perceive that there would be flaws, yet they chose to not post their comments on it to websec nor inform the WG about their new draft. To make it easier in the future to coordinate the two drafts and possibly discuss and decide whether to boil down to one, it might make sense to inform websec about draft-perrin-tls-tack and have a discussion about it at some point there. Just my 5cents. On 05/06/12 23:01, Paul Hoffman wrote: > On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote: > >>> The similarity of pinning and DANE has been discussed before. DANE relies on DNSSEC being deployed, which key-pinning does not. > Correct. Further, key-pinning in HTTP only applies to HTTP and relies on the client being able to establish a TLS session using non-key-pinning semantics. Key-pinning in TLS relies works with any lower-layer protocol and relies on the client being able to establish a TLS session using non-key-pinning semantics. > >>> Come to think of it, the draft needs a section comparing with DANE, but that's for another thread. >>> >>> draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Instead of the pins getting attested to in HTTP headers, you have a special public/private key pair, that you use to sign the SPKI from the server certificate within the a TLS extension. Like key-pinning there's a TOFU element here, because the client only learns about the special key when it encounters it in a TLS handshake. >>> >>> The obvious question is why would we need both key-pinning and tack. > It would be clearer if you said "both key-pinning in HTTP and key-pinning in TLS (tack)". > > --Paul Hoffman > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From touch@isi.edu Wed Jun 6 13:27:17 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B1C21F8505; Wed, 6 Jun 2012 13:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 3pWDLdL0+g6A; Wed, 6 Jun 2012 13:27:16 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7566A21F84CF; Wed, 6 Jun 2012 13:27:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q56KQsRS018230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jun 2012 13:26:54 -0700 (PDT) Message-ID: <4FCFBD0E.1070603@isi.edu> Date: Wed, 06 Jun 2012 13:26:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eliot Lear References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <4FCF2271.6090705@cisco.com> In-Reply-To: <4FCF2271.6090705@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, "saag@ietf.org" Subject: Re: [saag] [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:27:17 -0000 On 6/6/2012 2:27 AM, Eliot Lear wrote: > Joe, > > I support the development of this draft, and would be willing to provide > you with both content and editorial assistance. I would ask that (at > least) one additional important question be considered by this group and > the security area: > > * Is a request for a static port assignment in order to accommodate > firewalls still an appropriate reason? Good point - I think that this is still inevitable for one assignment. FWIW, I don't see a reason for 6 of anything - separate connections to a single port can often suffice in such cases, and firewall management for more than one port is complex (what happens when only a subset of the ports are open? how do you know, and how do you recover?). Joe > > I ask this question because there have been applications for as many as > six ports for related or very similar services that could all be > dynamically discovered from one. Some come back and say that they are > concerned that firewalls will prevent the service from functioning > properly. What is the IETF's point of view on this? > > Eliot > > On 6/5/12 2:08 AM, Joe Touch wrote: >> Hi, all, >> >> I've resubmitted this as a WG doc. The major changes were to include >> full references for previous placeholders and a few minor notes. >> >> It would be useful to get feedback on whether there are any areas that >> should be addressed that are not listed before diving into the two key >> issues I hope we can discuss as part of this doc: >> >> - whether to deprecate the distinction between system and >> user ports (or to do nothing at this time) >> >> - whether to make stronger recommendations on the use of >> security on port services (i.e., whether security "should" >> be supported for new services, or to make no specific >> recommendation at this time) >> >> Any gap material notes would be most useful now, though. >> >> Joe >> >> On 5/31/2012 11:34 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Transport Area Working >>> Group Working Group of the IETF. >>> >>> Title : Recommendations for Transport Port Uses >>> Author(s) : Joe Touch >>> Filename : draft-ietf-tsvwg-port-use-00.txt >>> Pages : 11 >>> Date : 2012-05-30 >>> >>> This document provides recommendations to application and service >>> designers on how to use the transport protocol port number space to >>> help in its preservation. **NOTE THAT THIS CURRENT VERSION IS >>> LARGELY AN OUTLINE OF ISSUES**. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt >>> >>> The IETF datatracker page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ >>> >> >> From touch@isi.edu Wed Jun 6 17:35:00 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD821F8552 for ; Wed, 6 Jun 2012 17:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 i1KcypYvmAny for ; Wed, 6 Jun 2012 17:35:00 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1992221F8448 for ; Wed, 6 Jun 2012 17:35:00 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q570Ymah006298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jun 2012 17:34:48 -0700 (PDT) Message-ID: <4FCFF728.6000303@isi.edu> Date: Wed, 06 Jun 2012 17:34:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: saag@ietf.org References: <4FBD6A78.2070204@cs.tcd.ie> <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> <4FBD873D.3090802@isi.edu> In-Reply-To: <4FBD873D.3090802@isi.edu> Content-Type: multipart/mixed; boundary="------------050909000709030701060806" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 00:35:00 -0000 This is a multi-part message in MIME format. --------------050909000709030701060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI - see attached notice for the port-use doc in TSVWG. Joe On 5/23/2012 5:56 PM, Joe Touch wrote: > > > On 5/23/2012 4:51 PM, Mouse wrote: >>> Short version: go read [RFC 3365] and say if you think it needs an >>> update. >> >> Yes, but I believe it's not one you're willing to accept. >> >>> "MUST implement strong security in all protocols" > > To open a can of worms, this would also be a good doc in which to > discuss the need for secure ports, and whether (or not) to ever assign > meaning to the difference between system and user ports... > > I was hoping to potentially open those discussions on TSVWG regarding > the user-ports draft, but it might also be relevant here. I'm not sure > if either will come to conclusion, but a round of discussion seems in > order. > > Joe --------------050909000709030701060806 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q516Ye0B018742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 May 2012 23:34:42 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q516YJxV016885; Thu, 31 May 2012 23:34:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27D021F85E1; Thu, 31 May 2012 23:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1338532459; bh=TFHQCw+nlkXsUvvLYPaauMFaN+cvoLYlmkRhoZaQnY8=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Message-ID:Date:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=OrgeY+m0A/o1ucfLXavZxUyolJC2R6/BF9Hx1cihScSsSCZxjMrDxmku+w/6YEgoW wdCnaBNMDaqjoJbjOHg4dQR0yr3b9T+QSKv/iTiRLB67wQJcOn3deuTD6SAI8UOlyS RkNgKrsUpuLJaYrh4tpf8sfjjIETOo7npgkCtTNo= X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251D921F85E1; Thu, 31 May 2012 23:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 0lBNd0ZciPFC; Thu, 31 May 2012 23:34:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933C221F85E3; Thu, 31 May 2012 23:34:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2012 23:34:17 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: tsvwg-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id q516Ye0B018742 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Recommendations for Transport Port Uses Author(s) : Joe Touch Filename : draft-ietf-tsvwg-port-use-00.txt Pages : 11 Date : 2012-05-30 This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. **NOTE THAT THIS CURRENT VERSION IS LARGELY AN OUTLINE OF ISSUES**. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-port-use-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ --------------050909000709030701060806-- From nico@cryptonector.com Wed Jun 6 18:49:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444E011E80C1 for ; Wed, 6 Jun 2012 18:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 tb4QVKotiGud for ; Wed, 6 Jun 2012 18:49:36 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 82C1B11E80B1 for ; Wed, 6 Jun 2012 18:49:36 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id F03F41B4058 for ; Wed, 6 Jun 2012 18:49:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=IS3/UxZ73m0EfwIrBt3K5XKq8+pdwTOButhJs3xnZx48 hmxdDvRUAGiOdTSsWBkMyFGOJ2M8cbocbq61xtSkkZZS8IVs28t+flsqKgcYoC0n ufi+Gy5TI/XTcd9BPaENBcwYr1t1J3bB9aoQIrZ1HW0B9cxESwGPj7SkcJhVlMc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=5PBNXyV0o5ib9rrQf/EdGjJ6/ss=; b=sSQvTcutdBh 7nC4M6ll31vw1of2QIGmRlv/6PjiuypMfNtXq6RdBjC5zgXRIMTYiDlF3hZYwKbN bcdU+pvM9GcYpATvXOK/mSf3sk6uCCPTg7SS4bpPlUhKdBm7XJ1FXz+X/28LbH/M yMzGKQ5eMyRvePv5unPpXlnBJPHVA5hw= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E055D1B4057 for ; Wed, 6 Jun 2012 18:49:35 -0700 (PDT) Received: by dacx6 with SMTP id x6so129383dac.31 for ; Wed, 06 Jun 2012 18:49:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.203.7 with SMTP id km7mr4347530pbc.7.1339033775466; Wed, 06 Jun 2012 18:49:35 -0700 (PDT) Received: by 10.68.15.134 with HTTP; Wed, 6 Jun 2012 18:49:35 -0700 (PDT) In-Reply-To: <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG> References: <4FBD6A78.2070204@cs.tcd.ie> <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> <4FC4EBA7.9070106@cs.tcd.ie> <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG> Date: Wed, 6 Jun 2012 20:49:35 -0500 Message-ID: From: Nico Williams To: Mouse Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] should we revise rfc 3365? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 01:49:37 -0000 On Tue, May 29, 2012 at 11:13 AM, Mouse wrote: >>>> "MUST implement strong security in all protocols" >>> I believe this is too dogmatic a position, and will simply lead to >>> IETF process being ignored in [some cases]. >> So how would you phrase it so that we do get security mechanisms >> defined in most all cases but not when they're really really not >> needed (or fictional)? > > I don't think that can be done by drawing a hard line in the sand, as > 3365 tries to do, regardless of where that line is drawn. =C2=A0Whether > strong security is appropriate is a judgement call, as is how much > security constitutes `strong' for a particular purpose. =C2=A0And judgeme= nt > calls have this annoying property that they require, well, judgement, > that they can't be made by unambiguous algorithms. > > It's possible I'm just missing something, but I can't see any way to do > this that doesn't mean involving real humans. =C2=A03365 appears to be > trying to do it in a way that avoids needing to involve humans; So let's give guidance. Something like: "It should be possible to implement and deploy Internet protocols securely vis-a-vis the Internet threat model. Some protocols can have no security features and still result in deployable security. For example, it is possible to use IP without having to deploy IPsec and yet obtain decent protection -against adversaries per the Internet threat model- by using TLS or other suitable protocols. In fact, quite a few Internet protocols can be deployed with no security functionality and the resulting systems can still be secure in the Internet threat model: ARP, IP, UDP, TCP, DHCP, etcetera. Additionally, low-value services need not require any security functionality in the protocol. For some protocols a security option is desirable, such as in IP (IPsec) and DNS (DNSSEC), for some a security option would be unwelcome (e.g., UDP, DHCP), while other protocols absolutely must have security options. In general high-value (or potentially high-value) applications require security options (e.g., HTTP applications)." IMO security choices generally (but not always) belong in the application layer, though session security doesn't necessarily (e.g., TLS is below the application layer). Deploying real, end-to-end security at the IP layer (IPsec) is currently so difficult that it cannot be scaled to the Internet, while deploying decent security at the link layer is feasible and desirable but cannot address the Internet threat model (due to the link layer inherently not being end-to-end). Nico -- From benlaurie@gmail.com Thu Jun 7 03:22:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFCF21F86CE for ; Thu, 7 Jun 2012 03:22:47 -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 7Ai5YE6aBSXb for ; Thu, 7 Jun 2012 03:22:47 -0700 (PDT) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5521F86C8 for ; Thu, 7 Jun 2012 03:22:46 -0700 (PDT) Received: by vbmv11 with SMTP id v11so383175vbm.27 for ; Thu, 07 Jun 2012 03:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=o2qBUVuUwtbkoKIM3umTN3wxIB9KdCs5i7kotnb0mao=; b=QVztxfBTXZVi0z1AhGnhtT9I+DHdx9sRIIxYnokx0qIR0s4UkSWj1OZ1qgx+iU3FpX 6TB9Hqh6Kv4rPOxHcY1EvlMAJRNBn8jCwCLTA98CYZY+CTqmBDwwnx5YhYzFhl5m81T4 AG2+RP45iIBx8RHk8bOj46s5gjRY+2aQF1+k8G1aKnbq6sg1NC0dkex0cOW9QhCrPymj WrEZpAJL8hZEcngKIrORDdJx8nBCEEd4n899sJKfSuFI/XVKRfgr7nki7JjBwyr+3bOj EMJNqtbRVz/Ln95Ec2sIMnraPJYmitipZ6AydH0fs3O/6Wy2ZW4avclEgYyPcJpFQXKi gIQw== MIME-Version: 1.0 Received: by 10.52.23.144 with SMTP id m16mr1253042vdf.77.1339064566193; Thu, 07 Jun 2012 03:22:46 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.52.36.226 with HTTP; Thu, 7 Jun 2012 03:22:46 -0700 (PDT) In-Reply-To: <4FCE6431.6050808@ieca.com> References: <4FCE6431.6050808@ieca.com> Date: Thu, 7 Jun 2012 11:22:46 +0100 X-Google-Sender-Auth: U5gbiWWy66CKfqwrIBBbm5iqApc Message-ID: From: Ben Laurie To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] Pinning X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 10:22:48 -0000 On Tue, Jun 5, 2012 at 8:55 PM, Sean Turner wrote: > All, > > There are many proposals for how to say which key or certificate or trust > anchor should be used by the client in a TLS session that it is about to > open. These proposals include making that decision in the DNS > (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the > application after TLS has happened once, to be remembered in the future > (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in > the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). > If more than one of these protocols are deployed, operational mistakes could > lead to a client getting conflicting information. You forgot Certificate Transparency :-) http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf > Similarly, there are also proposals on how to say whether or not a client > should expect to see a particular service running under TLS. These proposals > include making that indication in the DNS (draft hoffman-server-has-tls, > expired but might be revived) and in the application after TLS has happened > once, to be remembered in the future > (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport sec/). > If more than one of these protocols are deployed, operational mistakes could > lead to a client getting conflicting information. > > Is a standards-track operations statement needed to describe the choices > that a TLS server administrator has, and to deal with conflicts between the > proposals? > > spt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From alcaraz@lcc.uma.es Fri Jun 8 03:16:06 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7821F86AA for ; Fri, 8 Jun 2012 03:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.546 X-Spam-Level: X-Spam-Status: No, score=-5.546 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 dmAdUfdruQqS for ; Fri, 8 Jun 2012 03:16:01 -0700 (PDT) Received: from correo2.satd.uma.es (correo2.satd.uma.es [150.214.57.2]) by ietfa.amsl.com (Postfix) with ESMTP id 074A221F86A2 for ; Fri, 8 Jun 2012 03:16:01 -0700 (PDT) Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by correo2.satd.uma.es (Postfix) with ESMTP id 7B1E0118125 for ; Fri, 8 Jun 2012 12:15:53 +0200 (CEST) Received: from webmail.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by sol10.lcc.uma.es (Postfix) with ESMTP id 628464B008C for ; Fri, 8 Jun 2012 12:15:53 +0200 (CEST) MIME-Version: 1.0 Date: Fri, 08 Jun 2012 12:15:53 +0200 From: Cristina Alcaraz To: Message-ID: <937733155c7a362abe9c00f95bc45f16@lcc.uma.es> X-Sender: alcaraz@lcc.uma.es User-Agent: RoundCube Webmail/0.3.1 Content-Type: multipart/alternative; boundary="=_c23c48f18195575c1bb59ed861f59340" X-SATD-MailScanner-Information: Please contact the ISP for more information X-SATD-MailScanner-ID: 7B1E0118125.AD831 X-SATD-MailScanner: Found to be clean X-SATD-MailScanner-From: alcaraz@lcc.uma.es Subject: [saag] =?utf-8?q?CFP=3A_7th_International_Workshop_on_Critical?= =?utf-8?q?=C2=A0Information_Infrastructures_Security_=28CRITIS_201?= =?utf-8?q?2=29?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:16:07 -0000 --=_c23c48f18195575c1bb59ed861f59340 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 ** Apologies for multiple copies ** C a l l F o r P a p e r s 7th International Workshop on Critical Information Infrastructures Security (CRITIS 2012) Radisson Blu Lillehammer Hotel Turisthotellveien 6, 2609 Lillehammer, Norway September 17-18, 2012 http://critis12.hig.no/ Scope of the 7th Conference Critical key sectors of modern economies depend highly on Information and Communication Technologies (ICT). Disruption, disturbance or loss of information flowing through and processed by ICT infrastructures can, as well as incidents in the sector infrastructure itself, lead to various damages such as high economical, material, or ecological impact, loss of vital societal functions and social well-being of people, and in the most unfortunate cases loss of human lives. As a consequence the security, reliability and resilience of these infrastructures are critical for the society. The topic of Critical (Information) Infrastructure Protection (C(I)IP) is therefore a major objective for governments, companies and the research community of the major industrial countries worldwide. The CRITIS'12 conference is the well-established continuation of the series and aims to explore the new challenges posed by C(I)IP bringing together researchers and professionals from academia, industry and governmental agencies interested in all different aspects of C(I)IP. Especially promoted by CRITIS'12 are multi-disciplinary approaches within the scientific communities at national, European and global level. Authors are solicited to contribute to the conference by submitting research papers, work-in-progress reports, R"> Resilient (Information) Infrastructures * Resilience and Stability * Infrastructures Survivability * Protection of Complex Cyber - Physical Systems * All Aspects in respect to Interaction of multiple CI. * Self-healing, Self-protection, and Self-management Architectures * Cyber Threats and Vulnerabilities * SCADA Security * Cyber Attacks and Cyber Defence of Critical Information(-based) Infrastructures * Cyber Security of Smart Grids * Cyber Security, Dependability and Cloud Computing * Critical (Information-based) Infrastructures Exercises "> Advanced Forensic Methodologies for C(I)I * Economics, Investments and Incentives of C(I)IP * Infrastructure and CII dependencies Modelling, Simulation, Analysis and Validation * C(I)I Network and Organisational Vulnerability Analysis * C(I)I threat and Attack Modelling * Trust Models in Normal Situations and During Escalation * Public - Private Partnership for C(I)I Resilience * C(I)IP Polices at National and Cross-border levels * C(I)IP R&D Agenda at National and International levels Instructions for Paper Submission All submissions will be subjected to a thorough blind review by at least three reviewers. Papers should be no longer than 12 pages in English, including bibliography and well-marked appendices. As in previous years, it is planned that post-proceedings are published by Springer-Verlag in the Lecture Notes in Computer Science series. Pre-proceedings will appear at the time of the conference. At least one author of each accepted paper is required to register with the Conference and present the paper. Paper submission will be done via EasyChair. To submit a paper, please follow the specific instructions posted on the Conference website (http://critis12.hig.no/call-for-papers/). The submitted paper (in PDF or PostScript format) should follow the respective template offered by Springer (http://www.springer.de/comp/lncs/authors.html). The paper must start with a title, a short abstract, and a list of keywords. However, the submission should be anonymised and all author names, affiliations, acknowledgements, and obvious traceable references should be eliminated. Extended and fully revised versions of the best papers accepted for CRITIS'12, after a further peer-reviewed process, will be published in a special issue of the International Journal of Critical Infrastructures (Inderscience). Important Dates Deadline for submission of papers: extended to June 11, 2012 (from May 15, 2012) Notification to authors: extended to July 12, 2012 (from June 30, 2012) Camera-ready papers: August 15, 2012 Programme Committee Co-Chairs Bernhard M. Hämmerli (University of Applied Sciences Lucerne, Switzerland, Gjøvik University College, Norway, and CEO Acris GmbH) Javier Lopez (University of Malaga, Spain) Programme Committee (Invitations are sent out, confirmations partly pending) Eirik Albrechtsen (SINTEF and Norwegian University of Science and Technology, Norway) Jan Audestad (Gjøvik University College, Norway) Robin Bloomfield (City University London, UK) Matt Broda (Microsoft, UK) João Batista Camargo (University of São Paulo, Brazil) Genseric Cantournet (Telecom Italia, Italy) Emiliano Casalicchio (Università di Tor Vergata, Italy) Jorge Cuellar (Siemens, Germany) Peter Daniel (Selex Communication Ltd, UK) Gregorio D'Agostino (ENEA, Italy) Geert Deconinck (K. U. Leuven, Belgium) Giovanna Dondossola (RSE, Italy) Stelios Dritsas (Athens Univ. of Economics & Business, Greece) Myriam Dunn (ETH Centre for Security Studies, Switzerland) Claudia Eckert (Fraunhofer AISEC, Germany) Steven Furnell (Univ. of Plymouth, UK) Richard Garber (DRDC Centre for Security Science, Canada) Robert Ghanea-Hercock (British Telecom, UK) Adrian Gheorghe (Old Dominion University, USA) Janusz Gorski (Gdansk University of Technology, Poland) Stefanos Gritzalis (University of the Aegean, Greece) Jan Hovden (Norwegian University of Science and Technology, Norway) Jorge L. Hernandez-Ardieta (INDRA, Spain) Chris Johnson (Glasgow University, UK) Floor Koornneef (Delft University of Technology, The Netherlands) Panos Kotzanikolaou (Univ. of Piraeus, Greece) Eric Luiijf (TNO, The Netherlands) Paulo Maciel (Federal University of Pernambuco, Brazil) Fabio Martinelli (CNR, Italy) Marcelo Masera (EU Joint Research Centre Petten, The Netherlands) Amin Massoud (University of Minnesota, USA) Tom McCutcheon (Defence Science and Technology Laboratory, UK) Doug Montgomery ( U.S. National Institutes of Standards and Technology, USA) Igor Nai Fovino (Foundation Global Cyber Security, Italy) Janne Hagen (Proactima, Norway) Eiji Okamoto (University of Tsukuba, Japan) Cirian Osborn (Centre for the Protection of National Infrastructure, UK) Evangelos Ouzounis (European Network and Information Security Agency, Greece) Stefano Panzieri (University Roma Tre, Italy) Margrete Raaum, CERT University of Oslo, Norway Dirk Reinermann (German Information Security Agency, Germany) Arturo Ribagorda (Univ. Carlos III, Spain) Andrea Rigoni (Global CyberSecurity Center, Italy) Steven M. Rinaldi (Sandia National Laboratories, USA) Erich Rome (Fraunhofer IAIS, Germany) Andre Samberg (Sec-Control, Finland, and IMG-S TA2, European Union) Michael Samsa (Argonne National Laboratories, USA) William H. Sanders (University of Illinois, USA) Roberto Setola (Università CAMPUS Bio-Medico, Italy) Sujeet Shenoi (University of Tulsa, USA) James P. Smith (Los Alamos National Laboratories, USA) Angelos Stavrou (George Mason University, USA) Ketil Stølen (SINTEF and University of Oslo, Norway) Neeraj Suri (TU Darmstadt, Germany) Nils Kalstad Svendsen (Gjøvik University College, Norway) Barend Taute (Council for Scientific and Industrial Research, South Africa) Marianthi Theoharidou (Athens Univ. of Economics & Business, Greece) Paul Theron (Thales Information Systems Security, France) Panagiotis Trimintzios, Network Resilience, ENISA, EU Greece Paul Trushell (Attorney General's Department, Australia) Rita A. Wells (Idaho National Lab., USA) Paolo Verissimo (Universidad de Lisboa) Rhys Williams (Centre for the Protection of National Infrastructure, UK) Stephen Wolthusen (Gjøvik University College, Norway and Royal Holloway, U. of London, UK) Christos Xenakis (University of Piraeus, Greece) Annemarie Zielstra (Centre for the Protection of National Infrastructure, NL) Steering Committee Chairs Bernhard M. Hämmerli (University of Applied Sciences Lucerne, Switzerland, Gjøvik University College, Norway, and CEO Acris GmbH) Javier Lopez (University of Malaga, Spain) Steering Committee Members Robin Bloomfield (City University London, UK) Sandro Bologna (AIIC, Italy) Sokratis Katsikas (University of the Aegean, Greece) Reinhard Posch (Technical Univ. Graz, Austria) Saifur Rahman (Advanced Research Institute, Virginia Tech, US) Roberto Setola (Università CAMPUS Bio-Medico, Italy) Eric Rome (Fraunhofer IAIS, Germany) Stephen Wolthusen (Gjøvik University College, Norway and Royal Holloway, U. of London, UK) --=_c23c48f18195575c1bb59ed861f59340 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

** Apologies for multiple copies **

 

C a l l     F o r     P a p e r s

 

7th International Workshop on 

Critical Information Infrastructures Security (CRIT= IS 2012)

 

Radisson Blu Lillehammer Hotel

Turisthotellveien 6, 2609 Lillehammer, Norway

 

September 17-18, 2012

 

http://critis12.hig.no/ 

 

 

 

Scope= of the 7th Conference

 

Criti= cal key sectors of modern economies depend highly on Information and Commun= ication Technologies (ICT). Disruption, disturbance or loss of information = flowing through and processed by ICT infrastructures can, as well as incide= nts in the sector infrastructure itself, lead to various damages such as hi= gh economical, material, or ecological impact, loss of vital societal funct= ions and social well-being of people, and in the most unfortunate cases los= s of human lives. As a consequence the security, reliability and resilience= of these infrastructures are critical for the society. The topic of Critic= al (Information) Infrastructure Protection (C(I)IP) is therefore a major ob= jective for governments, companies and the research community of the major = industrial countries worldwide. 

 

The C= RITIS’12 conference is the well-established continuation of the serie= s and aims to explore the new challenges posed by C(I)IP bringing together = researchers and professionals from academia, industry and governmental agen= cies interested in all different aspects of C(I)IP. Especially promoted by = CRITIS’12 are multi-disciplinary approaches within the scientific com= munities at national, European and global level. 

 

Autho= rs are solicited to contribute to the conference by submitting research pap= ers, work-in-progress reports, R&D project results, surveying works and= industrial experiences describing significant advances in C(I)IP. Topics o= f interest include, but are not limited to:

 

&bull= ; Resilient (Information) Infrastr= uctures 

&bull= ; Resilience and Stability

&bull= ; Infrastructures Survivability

&bull= ; Protection of Complex Cyber - Ph= ysical Systems

&bull= ; All Aspects in respect to Intera= ction of multiple CI. 

&bull= ; Self-healing, Self-protection, a= nd Self-management Architectures

&bull= ; Cyber Threats and Vulnerabilitie= s

&bull= ; SCADA Security

&bull= ; Cyber Attacks and Cyber Defence = of Critical Information(-based) Infrastructures

&bull= ; Cyber Security of Smart Grids

&bull= ; Cyber Security, Dependability an= d Cloud Computing

&bull= ; Critical (Information-based) Inf= rastructures Exercises & Contingency Plans

&bull= ; Advanced Forensic Methodologies = for C(I)I

&bull= ; Economics, Investments and Incen= tives of C(I)IP

&bull= ; Infrastructure and CII dependenc= ies Modelling, Simulation, Analysis and Validation

&bull= ; C(I)I Network and Organisational= Vulnerability Analysis

&bull= ; C(I)I threat and Attack Modellin= g

&bull= ; Trust Models in Normal Situation= s and During Escalation

&bull= ; Public – Private Partnersh= ip for C(I)I Resilience

&bull= ; C(I)IP Polices at National and C= ross-border levels

&bull= ; C(I)IP R&D Agenda at Nationa= l and International levels

 

Instr= uctions for Paper Submission

 

All s= ubmissions will be subjected to a thorough blind review by at least three r= eviewers. Papers should be no longer than 12 pages in English, including bi= bliography and well-marked appendices. As in previous years, it is planned = that post-proceedings are published by Springer-Verlag in the Lecture Notes= in Computer Science series. Pre-proceedings will appear at the time of the= conference. At least one author of each accepted paper is required to regi= ster with the Conference and present the paper. Paper submission will be do= ne via EasyChair. To submit a paper, please follow the specific instruction= s posted on the Conference website (http://critis12.hig.no/call-for-papers/= ). The submitted paper (in PDF or PostScript format) should follow the resp= ective template offered by Springer (http://www.springer.de/comp/lncs/autho= rs.html). The paper must start with a title, a short abstract, and a list o= f keywords. However, the submission should be anonymised and all author nam= es, affiliations, acknowledgements, and obvious traceable references should= be eliminated.

Exten= ded and fully revised versions of the best papers accepted for CRITIS&rsquo= ;12, after a further peer-reviewed process, will be published in a special = issue of the International Journal of Critical Infrastructures (Inderscienc= e).

 

Impor= tant Dates

 

Deadl= ine for submission of papers: extended to June 11, 2012 (from May 15, 2012)=

Notif= ication to authors: extended to July 12, 2012 (from June 30, 2012)

Camer= a-ready papers: August 15, 2012

 

Progr= amme Committee Co-Chairs

 

Bernh= ard M. Hämmerli (University of Applied Sciences Lucerne, Switzerland, = Gjøvik University College, Norway, and CEO Acris GmbH)

Javie= r Lopez (University of Malaga, Spain)

 

Progr= amme Committee (Invitations are sent out, confirmations partly pending)

 

Eirik= Albrechtsen (SINTEF and Norwegian University of Science and Technology, No= rway)

Jan A= udestad (Gjøvik University College, Norway)

Robin= Bloomfield (City University London, UK)

Matt = Broda (Microsoft, UK)

Jo&at= ilde;o Batista Camargo (University of São Paulo, Brazil)

Gense= ric Cantournet (Telecom Italia, Italy)

Emili= ano Casalicchio (Università di Tor Vergata, Italy)

Jorge= Cuellar (Siemens, Germany)

Peter= Daniel (Selex Communication Ltd, UK)

Grego= rio D’Agostino (ENEA, Italy)

Geert= Deconinck (K. U. Leuven, Belgium)

Giova= nna Dondossola (RSE, Italy)

Steli= os Dritsas (Athens Univ. of Economics & Business, Greece)

Myria= m Dunn (ETH Centre for Security Studies, Switzerland)

Claud= ia Eckert (Fraunhofer AISEC, Germany)

Steve= n Furnell (Univ. of Plymouth, UK)

Richa= rd Garber (DRDC Centre for Security Science, Canada)

Rober= t Ghanea-Hercock (British Telecom, UK)

Adria= n Gheorghe (Old Dominion University, USA)

Janus= z Gorski (Gdansk University of Technology, Poland) 

Stefa= nos Gritzalis (University of the Aegean, Greece)

Jan H= ovden (Norwegian University of Science and Technology, Norway)

Jorge= L. Hernandez-Ardieta (INDRA, Spain)  

Chris= Johnson (Glasgow University, UK)

Floor= Koornneef (Delft University of Technology, The Netherlands)

Panos= Kotzanikolaou (Univ. of Piraeus, Greece)

Eric = Luiijf (TNO, The Netherlands)

Paulo= Maciel (Federal University of Pernambuco, Brazil)

Fabio= Martinelli (CNR, Italy)   

Marce= lo Masera (EU Joint Research Centre Petten, The Netherlands)

Amin = Massoud (University of Minnesota, USA)

Tom M= cCutcheon (Defence Science and Technology Laboratory, UK)

Doug = Montgomery ( U.S. National Institutes of Standards and Technology, USA)

Igor = Nai Fovino (Foundation Global Cyber Security, Italy)

Janne= Hagen (Proactima, Norway)

Eiji = Okamoto (University of Tsukuba, Japan)

Ciria= n Osborn (Centre for the Protection of National Infrastructure, UK)

Evang= elos Ouzounis (European Network and Information Security Agency, Greece)

Stefa= no Panzieri (University Roma Tre, Italy)

Margr= ete Raaum, CERT University of Oslo, Norway

Dirk = Reinermann (German Information Security Agency, Germany)

Artur= o Ribagorda (Univ. Carlos III, Spain)

Andre= a Rigoni (Global CyberSecurity Center, Italy)

Steve= n M. Rinaldi (Sandia National Laboratories, USA)

Erich= Rome (Fraunhofer IAIS, Germany)

Andre= Samberg (Sec-Control, Finland, and IMG-S TA2, European Union)

Micha= el Samsa (Argonne National Laboratories, USA)

Willi= am H. Sanders (University of Illinois, USA)

Rober= to Setola (Università CAMPUS Bio-Medico, Italy)

Sujee= t Shenoi (University of Tulsa, USA)

James= P. Smith (Los Alamos National Laboratories, USA)

Angel= os Stavrou (George Mason University, USA)

Ketil= Stølen (SINTEF and University of Oslo, Norway)

Neera= j Suri (TU Darmstadt, Germany)

Nils = Kalstad Svendsen (Gjøvik University College, Norway)

Baren= d Taute (Council for Scientific and Industrial Research, South Africa)

Maria= nthi Theoharidou (Athens Univ. of Economics & Business, Greece)

Paul = Theron (Thales Information Systems Security, France)

Panag= iotis Trimintzios, Network Resilience, ENISA, EU Greece

Paul = Trushell (Attorney General’s Department, Australia)

Rita = A. Wells (Idaho National Lab., USA)

Paolo= Verissimo (Universidad de Lisboa)

Rhys = Williams (Centre for the Protection of National Infrastructure, UK)

Steph= en Wolthusen (Gjøvik University College, Norway and Royal Holloway, = U. of London, UK)

Chris= tos Xenakis (University of Piraeus, Greece) 

Annem= arie Zielstra (Centre for the Protection of National Infrastructure, NL)

 

Steer= ing Committee Chairs

 

Bernh= ard M. Hämmerli (University of Applied Sciences Lucerne, Switzerland, = Gjøvik University College, Norway, and CEO Acris GmbH)

Javie= r Lopez (University of Malaga, Spain)

 

Steer= ing Committee Members

 

Robin= Bloomfield (City University London, UK)

Sandr= o Bologna (AIIC, Italy)

Sokra= tis Katsikas (University of the Aegean, Greece) 

Reinh= ard Posch (Technical Univ. Graz, Austria) 

Saifu= r Rahman (Advanced Research Institute, Virginia Tech, US)

Rober= to Setola (Università CAMPUS Bio-Medico, Italy)

Eric = Rome (Fraunhofer IAIS, Germany)

Steph= en Wolthusen (Gjøvik University College, Norway and Royal Holloway, = U. of London, UK)

--=_c23c48f18195575c1bb59ed861f59340-- From hartmans@mit.edu Fri Jun 8 15:33:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7140921F863F for ; Fri, 8 Jun 2012 15:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=-2.086, BAYES_00=-2.599, FAKE_REPLY_C=2.012, IP_NOT_FRIENDLY=0.334, 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 JNRw1Bz5Za8j for ; Fri, 8 Jun 2012 15:33:44 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C4E6E21F8639 for ; Fri, 8 Jun 2012 15:33:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4FF6120424 for ; Fri, 8 Jun 2012 18:33:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C44014151; Fri, 8 Jun 2012 18:33:25 -0400 (EDT) From: Sam Hartman To: saag@ietf.org Date: Fri, 08 Jun 2012 18:33:25 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [saag] Reminder: Call for Proposals - HTTP/2.0 and HTTP X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:33:44 -0000 On May 15, Nico and I had an exchange where I said that I thought authentication for things like ATOMPUB and other non-browser things on top of HTTP needed to happen at the HTTP layer rather than at the application layer. I was sort of surprised that we were disagreeing about that as we've discussed the problem multiple times. It turns out it was a semantic problem. I believe that if you're carrying an ATOMPUB request--for example trying to publish some web content, then whatever information you need in that POST request for authentication needs to be at the HTTP layer to fit well with the design of ATOMPUB. The sort of separation Nico is talking about works fine with that. In Nico's model, you may end up establishing an authentication session; how that's done is best handled above the HTTP request layer as Nico proposes. However once you get that session state there are some protocols where it seems like indicating the session in use is best done at the HTTP layer. We both seem to believe that's the case. So, it turns out there was no significant disagreement after all. From nico@cryptonector.com Fri Jun 8 16:16:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFE511E80E3 for ; Fri, 8 Jun 2012 16:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ZbfCp1BzqSeq for ; Fri, 8 Jun 2012 16:16:46 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4711E80E2 for ; Fri, 8 Jun 2012 16:16:45 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 08A14286059 for ; Fri, 8 Jun 2012 16:16:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; q=dns; s= cryptonector.com; b=YKs2hsG+alIWAtYAq1rwmQQxLQc629mYSKfDl9UAkA9U x8wVxLwUcYZQ9VydvtYgoQH5Aw3XKhIzXSWr3fkxrg6+b8RdPzXzL9QVWeSDdaBz CBfJl0I/5SDs97YJBPqCfP342CYQiTyrmkDMA9L0QF1E0y/W7PZu4FNm2j+SuLs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=3AtyX84UqZeIHdRN0YiP/5ddH08=; b=DCQQqfFD/hz gzIicCtPfzKKXrBxrTuOrn0imV0aBNQCtfkiH4Zw/qy08RXNQKLo1oJ6GhBsZVpm NotNPOXcz6rwMcGfx5PH09V6pYgm7MRw8aPd1nOs9umbAJArk/hEqpUBgvv2xAkl u/kgVBLgf3VAycpgEX0Us+3pkaR2Behw= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id E0D50286058 for ; Fri, 8 Jun 2012 16:16:44 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3150113pbc.31 for ; Fri, 08 Jun 2012 16:16:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.136.68 with SMTP id py4mr135234pbb.151.1339197404575; Fri, 08 Jun 2012 16:16:44 -0700 (PDT) Received: by 10.68.15.134 with HTTP; Fri, 8 Jun 2012 16:16:44 -0700 (PDT) Date: Fri, 8 Jun 2012 18:16:44 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: [saag] On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 23:16:47 -0000 Thanks Sam. Let me take this chance to summarize my vision of how to layer webauth: - API-wise, authentication message exchanges should happen at the HTTP layer. Rationale: one component can more easily take care of using TLS and webauth properly, including channel binding than two. - Network-layer-wise, that is, on the wire, authentication message exchanges should happen at the application layer. This works with HTTP/1.0, 1.1, and hopefully bis. In particular this means that authentication mechanisms with three or more messages require no changes to HTTP. - Authentication should result in a session URI that can be referenced from headers (see below) and which can be DELETEd to logout. - Application message exchanges (i.e., normal HTTP requests and responses) should be bear headers identifying the login session that they are part of. Optionally there should be a MAC to bind the request/response to its session, using session keys, of course. Nico -- From y.oiwa@aist.go.jp Fri Jun 8 19:15:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8C511E80CE for ; Fri, 8 Jun 2012 19:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.177 X-Spam-Level: X-Spam-Status: No, score=-7.177 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 mvdcE1Pw338R for ; Fri, 8 Jun 2012 19:15:07 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5123111E80A4 for ; Fri, 8 Jun 2012 19:15:07 -0700 (PDT) Received: from mail-ob0-f176.google.com ([209.85.214.176]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT9Kxqsok/eEOth/sfGZtMdKATS+Om2Jg@postini.com; Fri, 08 Jun 2012 19:15:07 PDT Received: by obbef5 with SMTP id ef5so4425685obb.35 for ; Fri, 08 Jun 2012 19:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=V76LbYI7jvpe8v9PIeZ4qRB+4u9tFrFv6X34wl4naGc=; b=mkKd738m7EHFnuP63UsyEtdUiBXKYW/S1wn+Gx165VRg3i+CygRdy05DTNm3K6R5Yb mNL/k37r/LmP1+MVY/yUAW6vQ9ID2B9PG5xEGcPgQEn3uQLYUK5Dd6egx1KB6Wu1IAzo TpVP7xgbSGdRB+wCeY5NAbrSpLe2b1OX8MMz4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=V76LbYI7jvpe8v9PIeZ4qRB+4u9tFrFv6X34wl4naGc=; b=NEvTb3ZXZsJJBOhzAxEfGPmI5d6+wuWdwmaXM8BK0SC3hJ7ncU1G0geqAsn2kT1tcF hZfMkG9pi68RDfyUB46nZSLPRdpaER6S3CWtbPjS/P22xvJwU4IccBCPS9gIZ6PqaKsl djPNdNGZkwG6TlnAMUFayEulgL1fgfM1gjci5ERY8U5HRBjPMgmXPGnvHaK66CrD1ooA oMHDN2dCSYRUlz1wzR7oDD92fwd7SZddWEFjm385iI7SAcxjBz0Bxzijm1d1PSxRBo+X vLdmnWK6rtupuxKW8xQ5bDJk4qgVhf9dwrD1UkWbqH53CmmVTWJiS2R1MB0UE1QzqkCk XvJw== Received: by 10.50.169.73 with SMTP id ac9mr3564027igc.29.1339208106083; Fri, 08 Jun 2012 19:15:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.65.6 with HTTP; Fri, 8 Jun 2012 19:14:45 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Sat, 9 Jun 2012 11:14:45 +0900 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkR5fdlCouwA9AHgCSPaAJsElNEQk2Coc31+Qd9jmZszvwpfvcLvaVlJGq5jnfBNLCndK53 Cc: Sam Hartman , saag@ietf.org Subject: Re: [saag] On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 02:15:08 -0000 Dear Nico, could you clarify the first two sentences without using terms like "API-wise" and "network-layer-wise"? The latter two sentences are clearer, although (as you may know) I disagree with some of them. It may be a good opportunity for my side, too. My position regarding layering is "there will be a REST-layer authentication framework which is really useful and worth standardization (possibly GSS-REST?). However, it should not be the only nor the default way of authentication for all HTTP applications in the next generation. Core authentication in HTTP should be in HTTP layer and it should be greatly improved, and, importantly, *it will work* (as we showed in the reference implementations), # Now is IETF trac wiki down? 2012/6/9 Nico Williams : > Thanks Sam. > > Let me take this chance to summarize my vision of how to layer webauth: > > =A0- API-wise, authentication message exchanges should > =A0 happen at the HTTP layer. =A0Rationale: one component > =A0 can more easily take care of using TLS and webauth > =A0 properly, including channel binding than two. > > =A0- Network-layer-wise, that is, on the wire, authentication > =A0 message exchanges should happen at the application > =A0 layer. > > =A0 This works with HTTP/1.0, 1.1, and hopefully bis. =A0In > =A0 particular this means that authentication mechanisms > =A0 with three or more messages require no changes to HTTP. > > =A0- Authentication should result in a session URI that can be > =A0 referenced from headers (see below) and which can be > =A0 DELETEd to logout. > > =A0- Application message exchanges (i.e., normal HTTP requests > =A0 and responses) should be bear headers identifying the login > =A0 session that they are part of. =A0Optionally there should be a > =A0 MAC to bind the request/response to its session, using > =A0 session keys, of course. > > Nico > -- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Yutaka OIWA, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0Leader, Software Reliability = Research Group =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Research Institu= te for Secure Systems (RISEC) =A0 =A0National Institute of Advanced Industrial Science and Technology (AI= ST) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D =A03139 8677 9BD2 4405 46= B5] From nico@cryptonector.com Mon Jun 11 12:37:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47EF11E809B for ; Mon, 11 Jun 2012 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 5G18wt3AHqI9 for ; Mon, 11 Jun 2012 12:37:05 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 10F1811E8091 for ; Mon, 11 Jun 2012 12:37:05 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 48C7E67C075 for ; Mon, 11 Jun 2012 12:37:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=IB5QcwM6H4QDPZBBGOW5C 2KfKf7ZZoHbdxXgm3EaXJxh2PsYCudh16Cr2KdS77M2PtGESA7TM/kTs1gFSmXu7 DAl+k9srsN+2gCBYB9gUZVVUwF9Wd4htR9TgYBsfklOtBng90c/zGbywMaVTltJM Joa0mHA0ISc6yCUqpYlENk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rSltNtan4u52i5/5Ngar idPC9Ek=; b=quic85BC4vR7nf+yXe+g04668R/OlVkX5Ag7vpFOMHwcPnnUqYi+ NI/2Wn5ZYFWsHyRSQJA/l1G10TJ1QGKwkgr9MtY7bjeOhdfoDkXjf9WD2c4bdYXM yulxCpC73NwKqy36wQyK6SWv3iAiD8THdn0/c5lwCMWVBiBCYRGGjPY= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 2F7C267C073 for ; Mon, 11 Jun 2012 12:37:04 -0700 (PDT) Received: by dacx6 with SMTP id x6so5809552dac.31 for ; Mon, 11 Jun 2012 12:37:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.101 with SMTP id rj5mr29304739pbc.103.1339443423901; Mon, 11 Jun 2012 12:37:03 -0700 (PDT) Received: by 10.68.15.134 with HTTP; Mon, 11 Jun 2012 12:37:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Jun 2012 14:37:03 -0500 Message-ID: From: Nico Williams To: Yutaka OIWA Content-Type: text/plain; charset=UTF-8 Cc: Sam Hartman , saag@ietf.org Subject: Re: [saag] On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 19:37:05 -0000 On Fri, Jun 8, 2012 at 9:14 PM, Yutaka OIWA wrote: > could you clarify the first two sentences without using > terms like "API-wise" and "network-layer-wise"? Sure. I want HTTP authentication to be at the application layer on the wire for various reasons, but I want it to be provided by the same APIs that provide HTTP and HTTPS support to the application. The reasons for wanting HTTP authentication to be at the application layer on the wire: - no leakage of information through the URL local part prior to completing authentication; - can be made to work with HTTP/1.0, HTTP/1.1, and HTTP/2.0; - can be implemented in the application when the HTTP APIs do not do so natively. I care deeply about all of the above. > The latter two sentences are clearer, although > (as you may know) I disagree with some of them. OK. Can you explain your disagreement? > It may be a good opportunity for my side, too. Indeed. > My position regarding layering is "there will be a > REST-layer authentication framework which is really useful > and worth standardization (possibly GSS-REST?). > However, it should not be the only nor the default way of > authentication for all HTTP applications in the next generation. I agree. I'm not trying to forbid the use of authentication mechanisms that already exist, for example. But I'm interested in why you want new authentication mechanisms at the HTTP layer (on the wire) that require more than one round trip. > Core authentication in HTTP should be in HTTP layer and > it should be greatly improved, and, importantly, *it will work* > (as we showed in the reference implementations), See my rationale given above for why authentication should be *above* HTTP on the wire. Nico -- From vishwas.ietf@gmail.com Tue Jun 12 11:15:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6999D21F8628 for ; Tue, 12 Jun 2012 11:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 Yq9ak8pzs1pt for ; Tue, 12 Jun 2012 11:15:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D00421F861D for ; Tue, 12 Jun 2012 11:15:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so4370142yhq.31 for ; Tue, 12 Jun 2012 11:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CR09khiPctlI8YvPFmdUTU/h+YfDH5feNUtFJrewlUI=; b=LgXJDLvMdpH5hJjLD2xK90WE+20wOLD38+udv50veVOuUenCpCtTg9oR8+X3Mqw9wj XxjDgehjGcO8fUuFvw5LxN20j/g6q9Q69UHYEPlnWuGt+WRj+y2PIsJ+DgPBKH+hFyQP HshPVvnMKI+tkU5LZNDLN0YAJgwNXe1NzH3YlJIuksuHUECBi+UNZiBCOKTKZwlcphmM 9lTUuyX74yeQMQoui2aFtx6w3LMCeenP1PqLPk5DzciwDoIBBf+iWzf1HD44Z9ft6oYs j/zCKoHVQ7KHBKtlWIOzn4829CQJzkd3pSHdEm6lM/BW/QE9d2Ylq0RnW6RJ8paK5oNf cHFQ== MIME-Version: 1.0 Received: by 10.60.8.8 with SMTP id n8mr2724735oea.38.1339524928041; Tue, 12 Jun 2012 11:15:28 -0700 (PDT) Received: by 10.182.214.33 with HTTP; Tue, 12 Jun 2012 11:15:28 -0700 (PDT) Date: Tue, 12 Jun 2012 11:15:28 -0700 Message-ID: From: Vishwas Manral To: IETF Security Area Advisory Group , IETF Security Area WG Content-Type: multipart/alternative; boundary=e89a8ff1c6d480f15604c24a73d6 Subject: [saag] Bitten by MD5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:15:29 -0000 --e89a8ff1c6d480f15604c24a73d6 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Thought this would be interesting to the group, especially since we have talked of issues with MD5 hash collisions in the past. This is about Flame and its use of MD5: http://mobile.techworld.com/news/security/3363162/flames-windows-update-hack-used-world-class-cryptanalysis-say-researchers/?cmpid=TD1N17&no1x1&olo=daily%20newsletter Thanks, Vishwas --e89a8ff1c6d480f15604c24a73d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

Thought this would be interesting to the group, especially= since we have talked of issues with MD5 hash collisions in the past. This = is about Flame and its use of MD5:
http://mobile.techworld.com/news/security/3363162/flames-windows-update= -hack-used-world-class-cryptanalysis-say-researchers/?cmpid=3DTD1N17&no= 1x1&olo=3Ddaily%20newsletter

Thanks,
Vishwas
--e89a8ff1c6d480f15604c24a73d6-- From kent@bbn.com Wed Jun 13 11:31:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBECB11E8079 for ; Wed, 13 Jun 2012 11:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.023 X-Spam-Level: X-Spam-Status: No, score=-107.023 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, GB_I_LETTER=-2, 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 tsHf9I6YmBku for ; Wed, 13 Jun 2012 11:31:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 24A0B11E8072 for ; Wed, 13 Jun 2012 11:31:24 -0700 (PDT) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49354) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SesL9-0005Io-At; Wed, 13 Jun 2012 14:30:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 13 Jun 2012 14:31:20 -0400 To: Vishwas Manral From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-872510213==_ma============" Cc: IETF Security Area WG , IETF Security Area Advisory Group Subject: Re: [saag] Bitten by MD5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:31:25 -0000 --============_-872510213==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:15 AM -0700 6/12/12, Vishwas Manral wrote: >Hi folks, > >Thought this would be interesting to the group, especially since we >have talked of issues with MD5 hash collisions in the past. This is >about Flame and its use of MD5: >http://mobile.techworld.com/news/security/3363162/flames-windows-update-hack-used-world-class-cryptanalysis-say-researchers/?cmpid=TD1N17&no1x1&olo=daily%20newsletter > >Thanks, >Vishwas The MD5 collision attack, as noted in the report details, does not appear to be really new and it could have been mitigated by following cert issuance guidelines that have been published for several years. I don't think there is anything noteworthy about this aspect of Flame, for folks who have tracked progress in this area for a while. Steve --============_-872510213==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] Bitten by MD5
At 11:15 AM -0700 6/12/12, Vishwas Manral wrote:
Hi folks,

Thought this would be interesting to the group, especially since we have talked of issues with MD5 hash collisions in the past. This is about Flame and its use of MD5:
http://mobile.techworld.com/news/security/3363162/flames-windows-update-hack-used-world-class-cryptanalysis-say-researchers/?cmpid=TD1N17&no1x1&olo=daily%20newsletter

Thanks,
Vishwas

The MD5 collision attack, as noted in the report details, does not appear to be really new and it could have been mitigated by following cert issuance guidelines that have been published for several years.

I don't think there is anything noteworthy about this aspect of Flame, for
folks who have tracked progress in this area for a while.

Steve
--============_-872510213==_ma============-- From paul.hoffman@vpnc.org Wed Jun 13 12:20:15 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8929811E8094 for ; Wed, 13 Jun 2012 12:20:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bop1LvPxFbb0 for ; Wed, 13 Jun 2012 12:20:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0384011E808C for ; Wed, 13 Jun 2012 12:20:14 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5DJK7Mm054888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Jun 2012 12:20:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 13 Jun 2012 12:20:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0596DAE3-ADD9-4A42-B45D-1C009B5A8846@vpnc.org> References: To: Stephen Kent X-Mailer: Apple Mail (2.1278) Cc: IETF Security Area Advisory Group Subject: Re: [saag] Bitten by MD5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 19:20:15 -0000 On Jun 13, 2012, at 11:31 AM, Stephen Kent wrote: > The MD5 collision attack, as noted in the report details, does not = appear to be really new and it could have been mitigated by following = cert issuance guidelines that have been published for several years. >=20 > I don't think there is anything noteworthy about this aspect of Flame, = for > folks who have tracked progress in this area for a while. The fact that the guidance had been published for many years, but = Microsoft ignored it, seems noteworthy. --Paul Hoffman From kent@bbn.com Wed Jun 13 13:12:28 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D0521F854A for ; Wed, 13 Jun 2012 13:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 A+vSQUOlLYXA for ; Wed, 13 Jun 2012 13:12:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7921F84DF for ; Wed, 13 Jun 2012 13:12:27 -0700 (PDT) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49362) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Setuw-0008eF-F6; Wed, 13 Jun 2012 16:11:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <0596DAE3-ADD9-4A42-B45D-1C009B5A8846@vpnc.org> References: <0596DAE3-ADD9-4A42-B45D-1C009B5A8846@vpnc.org> Date: Wed, 13 Jun 2012 16:04:09 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF Security Area Advisory Group Subject: Re: [saag] Bitten by MD5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:12:28 -0000 At 12:20 PM -0700 6/13/12, Paul Hoffman wrote: >On Jun 13, 2012, at 11:31 AM, Stephen Kent wrote: > >> The MD5 collision attack, as noted in the report details, does not >>appear to be really new and it could have been mitigated by >>following cert issuance guidelines that have been published for >>several years. >> >> I don't think there is anything noteworthy about this aspect of Flame, for >> folks who have tracked progress in this area for a while. > >The fact that the guidance had been published for many years, but >Microsoft ignored it, seems noteworthy. > >--Paul Hoffman agreed. Steve From SChokhani@cygnacom.com Fri Jun 15 11:23:08 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CDA21F85EE for ; Fri, 15 Jun 2012 11:23:08 -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 4Q2XRx-dWEPD for ; Fri, 15 Jun 2012 11:23:07 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id A9CEF21F85DF for ; Fri, 15 Jun 2012 11:23:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,779,1330923600"; d="scan'208";a="1195989" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 15 Jun 2012 14:23:04 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 15 Jun 2012 14:23:03 -0400 From: Santosh Chokhani To: Paul Hoffman , Stephen Kent Date: Fri, 15 Jun 2012 14:23:02 -0400 Thread-Topic: [saag] Bitten by MD5 Thread-Index: Ac1JmZYp+eq3P7LjQeaPIhCMlWziLwBibXVg Message-ID: References: <0596DAE3-ADD9-4A42-B45D-1C009B5A8846@vpnc.org> In-Reply-To: <0596DAE3-ADD9-4A42-B45D-1C009B5A8846@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Security Area Advisory Group Subject: Re: [saag] Bitten by MD5 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 18:23:08 -0000 When I read this blog, I come away with the impression that the way MSFT de= termines a certificate is a valid code signing certificate makes the attack= possible on XP and older platform even without hash collision attack. To my knowledge, Windows is happy to declare a digital signature certificat= e as code signer if there is no EKU, if there is "anyEKU" or if there is co= de signing EKU. Of course, there are other caveat such as CA certificate a= lso meet this EKU requirement, but these caveats are generally always true. http://blogs.technet.com/b/srd/archive/2012/06/06/more-information-about-th= e-digital-certificates-used-to-sign-the-flame-malware.aspx?Redirected=3Dtru= e -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Pau= l Hoffman Sent: Wednesday, June 13, 2012 3:20 PM To: Stephen Kent Cc: IETF Security Area Advisory Group Subject: Re: [saag] Bitten by MD5 On Jun 13, 2012, at 11:31 AM, Stephen Kent wrote: > The MD5 collision attack, as noted in the report details, does not appear= to be really new and it could have been mitigated by following cert issuan= ce guidelines that have been published for several years. >=20 > I don't think there is anything noteworthy about this aspect of Flame,=20 > for folks who have tracked progress in this area for a while. The fact that the guidance had been published for many years, but Microsoft= ignored it, seems noteworthy. --Paul Hoffman _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From y.oiwa@aist.go.jp Fri Jun 15 17:38:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96A311E808C for ; Fri, 15 Jun 2012 17:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.477 X-Spam-Level: X-Spam-Status: No, score=-7.477 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 kGY5R02Ud628 for ; Fri, 15 Jun 2012 17:38:40 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id DFC6711E807F for ; Fri, 15 Jun 2012 17:38:39 -0700 (PDT) Received: from mail-yx0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT9vVj0Ab5PSh4eXx+cR62L8qmILn08iJ@postini.com; Fri, 15 Jun 2012 17:38:39 PDT Received: by yenl2 with SMTP id l2so2379959yen.19 for ; Fri, 15 Jun 2012 17:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5o+q5jUGTx8R8xjhq61ZiUPWCN51Lu9rKxQ1VoQhqIs=; b=wDO3by2GZQ6mdhH+Jjp4L7iZWk6cLg/nTqWc4tqtuhTQW2zW8tAZrQdYM6lRHqTgbS aM0Xuxyv0s+MXwHSIYOpjpvsVP2/97SyDX/khbB1TkTDybL6OnXj4NvVsToHUQnYLdKa o1zbVp6mcNFofAraE3+9zoNHBkqsa+1/YIqug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=5o+q5jUGTx8R8xjhq61ZiUPWCN51Lu9rKxQ1VoQhqIs=; b=fktrRcDwtOVsf+T3VPKNgAbq7rDl8RkfKd32oJKVZgIIZsioWJIYcyWC3teyBPXlN3 ocxVDW60qS8e59w2IvhWDg4+UwDnc55MBy2TbKn6cyb/p/C7Pzkyz/yF0WBBIZVqQSGz 7wYEyoUDc7aX089AiuNoYerVw9IC3XVFLtJ5TviFkLwEEwGmzh6+e6Hd4Gl4FwP32hQQ CRuDXFh23KWXZeGGJnC8d8nlxLUkb5TFsrVtKPzZFiBSqTqVGoYtxBpz12N+QuL+jtDK DZwJ35hL/zdzQq/K7tXhJOvwq8DTvbcnWNf2UQjYKSD5ka9QPB5PNBsXEsz4VBJyi/Ov rdug== Received: by 10.50.161.199 with SMTP id xu7mr3580397igb.68.1339807118667; Fri, 15 Jun 2012 17:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.85.101 with HTTP; Fri, 15 Jun 2012 17:38:17 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Sat, 16 Jun 2012 09:38:17 +0900 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlubZzyywRFLYj+8BlMOKXGECd82Z/HeKMr78dNBpmQy7RDhcg+E2h7s1yA6WLukuyO27pv Cc: Sam Hartman , saag@ietf.org Subject: Re: [saag] On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 00:38:41 -0000 Dear Nico, 2012/6/12 Nico Williams : > On Fri, Jun 8, 2012 at 9:14 PM, Yutaka OIWA wrote: > But I'm interested in why you want new authentication mechanisms at > the HTTP layer (on the wire) that require more than one round trip. In a simple answer, we found that putting it in payload layer is unnatural for our solution. It is not our design principle, but the result= of our design analysis. Our foundational way of thinking is first to decide what problem will be so= lved, what solution can be used, how the communication will occur, and finally, how these things are put on the wire, considering all benefits and deficits there. I think that we should not put any protocol-implementation restrictions on the first priority (software implementation/deployment issue is important). Our design considerations is now described in http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals/MutualAut= h/LayeringDesigns As I described in the above document, HTTP payload and HTTP headers are isomorphic (in other words, exchangeable in design). However, if we think = of imaginary (non-existing) protocol which we move the key exchange messages of our Mutual authentication to the payload layer, we immediately see that it will not fit to real applications, will not fit our security requirements, will introduce unneeded complexities in both server and client sides, I strongly believe that, under such situation, we should not stick to specific layering philosophies but we should choose the best layering choices for each solution. I also like to mention that, we actually see several solutions for which payload-header hyblid solutions are well suited. The best example on our table is OAuth, obviously. I believe that you think your solution also fit to that solution. We will put one more document regarding such analysis around Monday (currently under personal proofreading). I think it will somewhat make clear why we see difference between appropriate design of layering for each solution. --=20 Yutaka OIWA, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0Leader, Software Reliability = Research Group =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Research Institu= te for Secure Systems (RISEC) =A0 =A0National Institute of Advanced Industrial Science and Technology (AI= ST) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D =A03139 8677 9BD2 4405 46= B5] From hannes.tschofenig@gmx.net Mon Jun 18 04:59:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB5821F85BD for ; Mon, 18 Jun 2012 04:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 UwwTHd6xeCt2 for ; Mon, 18 Jun 2012 04:59:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 30A6921F8562 for ; Mon, 18 Jun 2012 04:59:40 -0700 (PDT) Received: (qmail invoked by alias); 18 Jun 2012 11:59:40 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp039) with SMTP; 18 Jun 2012 13:59:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8/ioW+478wqdahXBkN0phfPHkSeORLUXlxvSl9x XC/fPCGdJM2PYn From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2012 14:59:38 +0300 Message-Id: <4A50B48D-7686-40A9-A089-7B08A8CDB741@gmx.net> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 11:59:42 -0000 Hi all,=20 I was wondering what the common practice is regarding error handling = with respect to security.=20 When I was student (a little while ago) I was always told that you do = not want to provide an attacker with additional information, including = information that is returned in error responses. This specifically had = an impact on the error handling procedures for authentication protocols.=20= For end users and developers it is obviously better to offer more = information to let them figure out what had gone wrong.=20 So, there seems to be a conflict.=20 Experience or views from others?=20 Ciao Hannes From jis@mit.edu Mon Jun 18 06:18:14 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9772521F8621 for ; Mon, 18 Jun 2012 06:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 SaFimFPjua8v for ; Mon, 18 Jun 2012 06:18:13 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id C6D1021F8611 for ; Mon, 18 Jun 2012 06:18:11 -0700 (PDT) X-AuditID: 1209190c-b7fb16d000000926-7b-4fdf2a92e038 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id A0.78.02342.29A2FDF4; Mon, 18 Jun 2012 09:18:11 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q5IDIATt020713 for ; Mon, 18 Jun 2012 09:18:10 -0400 Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) (authenticated bits=0) (User authenticated as jis@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q5IDI9j9006231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 18 Jun 2012 09:18:10 -0400 (EDT) Received: by ghbg16 with SMTP id g16so3978448ghb.31 for ; Mon, 18 Jun 2012 06:18:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.188.131 with SMTP id ga3mr371933igc.54.1340025488997; Mon, 18 Jun 2012 06:18:08 -0700 (PDT) Received: by 10.231.143.196 with HTTP; Mon, 18 Jun 2012 06:18:08 -0700 (PDT) In-Reply-To: <4A50B48D-7686-40A9-A089-7B08A8CDB741@gmx.net> References: <4A50B48D-7686-40A9-A089-7B08A8CDB741@gmx.net> Date: Mon, 18 Jun 2012 09:18:08 -0400 Message-ID: From: Jeffrey Schiller To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6nojtZ676/wcX3TBZT+juZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0b/9BmPBXomKGZ2X2RoYrwt3MXJySAiYSNxZPJ0RwhaTuHBv PVsXIxeHkMA+RolNnx8xQjhHGCV6Dq1khXBuM0ms/3+XGaRFSKBc4vP+Z6wgNq+AoMTJmU9Y IOIFElP2bWOEsH0k3vUcZQexOQWsJY5M3gTVayWxpX8xWJxFQFWi6+pbZog5ARJrz9wGs4UF dCW+XrnMBGKzCahIbHvXAhYXETCUuD5zOtheZqC9vbPeMUHYOhLv+h4wQ9jaEssWvmaewCg8 C8l5s5CUzUJStoCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuoV5uZoleakrpJkZQeHNK8uxg fHNQ6RCjAAejEg9vZcY9fyHWxLLiytxDjJIcTEqivEs07vsL8SXlp1RmJBZnxBeV5qQWH2KU 4GBWEuH9wQWU401JrKxKLcqHSUlzsCiJ815OuekvJJCeWJKanZpakFoEk5Xh4FCS4J2tCdQo WJSanlqRlplTgpBm4uAEGc4DNPwQSA1vcUFibnFmOkT+FKMxx7O3R24wckzrOXGDUYglLz8v VUqcdzlIqQBIaUZpHtw0WIp6xSgO9Jww7ymQKh5geoOb9wpoFRPQKinzOyCrShIRUlINjJxp Xp4K7dekuVUVvzk+qtUy61t78PO3za63o1N9uF1KPM++YypY9pHhX92Lzw+klRWaWtx2H+1R O3QkODf3Y7xKt3FW4YOtdxcntH4//+d/h/QdNc6Oh0WsQV3XFhYz/fA7GDSt8PGJuJ5jAnea RWrc9769s1XK2PWTU27/t7u6wne2LXHbq8RSnJFoqMVcVJwIAEjboNcsAwAA Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 13:18:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jun 18, 2012 at 7:59 AM, Hannes Tschofenig wrote: > When I was student (a little while ago) I was always told that you > do not want to provide an attacker with additional information, > including information that is returned in error responses. This > specifically had an impact on the error handling procedures for > authentication protocols. > > For end users and developers it is obviously better to offer more > information to let them figure out what had gone wrong. > > So, there seems to be a conflict. I believe the answer depends a lot on context and risk. Ask yourself the question: "If I give a 'useful' answer here how will I be empowering an attacker, what will they be able to do?" Let's consider the simple and obvious case of user login. If you say "username or password incorrect" [1], then you are divulging little information, but a legitimate user won't know which part she got wrong. On other hand if you say "no such user", then you have provided some small information to the attacker. The attacker can then use your login procedure as an Oracle to determine whether or not an account exists. But there are ways to thwart this attack somewhat. For example if someone provides a different invalid username say three times in a row, start returning "no such user" for all attempts, including ones where the user *is* correct and maybe even the password. Now three may not be the correct threshold. You want to set it high enough that you don't confuse legitimate users, but low enough that your login procedure cannot be used as a good Oracle. [2] So my point is that you have to look at the trade-offs involved in each situation and see if there is something you can do that preserves usefulness for legitimate users while thwarting attackers. -Jeff [1] We'll ignore the issue of whether or not passwords are a good authentication technology :-) [2] And in some situations even one "no such user" answer is not good. Consider the case of the porn site that uses e-mail addresses as login names. If you provide "no such user" only in the case where no such user really exists, then I can run your email address by their login procedure to see if you are a customer. Here the "harm" isn't compromising the site, but compromising the user :-) [This isn't original to me, I read about this cute possibility on-line, but I forget where] - -- _______________________________________________________________________ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue =A0Room E17-110A Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu http://jis.qyv.name _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFP3ypz8CBzV/QUlSsRApEOAKD0F2OJtIOHGjav6ygSqW3fCdUcLQCeOx5s ONVLo5w/jUh97gHWQHUwjLk=3D =3Do828 -----END PGP SIGNATURE----- From mouse@Sparkle.Rodents-Montreal.ORG Mon Jun 18 06:59:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347EC21F860F for ; Mon, 18 Jun 2012 06:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, 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 BISZAUIXQtiL for ; Mon, 18 Jun 2012 06:59:36 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5498721F8554 for ; Mon, 18 Jun 2012 06:59:36 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA21749; Mon, 18 Jun 2012 09:59:34 -0400 (EDT) Date: Mon, 18 Jun 2012 09:59:34 -0400 (EDT) From: Mouse Message-Id: <201206181359.JAA21749@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Mon, 18 Jun 2012 09:42:47 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4A50B48D-7686-40A9-A089-7B08A8CDB741@gmx.net> References: <4A50B48D-7686-40A9-A089-7B08A8CDB741@gmx.net> Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 13:59:37 -0000 > I was wondering what the common practice is regarding error handling with re$ Please don't use paragraph-length lines. > [security considerations indicate returning minimal info in eg error > resposnes, whereas developers and legitimate users want maximal info] > So, there seems to be a conflict. First, I'd remark that different cases have different needs. This is obvious enough, but the implication, that there is no one-size-fits-all answer, seems to be easy to miss. Knowing nothing about the particular case under consideration, if any, my own preference would be to, by default, record helpful information in server logs and return minimal information to the client. (By `server' I really mean `the peer performing the authentication' and by `client', `the peer being authenticated'. My remarks are aimed at authentication/authorization exchanges, but, mutatis mutandis, they can apply to others.) In many cases, it can also be reasonable to provide a way to configure the server to return more verbose information to the client, for cases where the cost of the additional information exposure is less than the benefit of the additional information; this can help when, for example, running client and server on a closed development network or when a server admin is trying to help diagnose a problem. In some cases it may be enough to just give clients out-of-band (with respect to the protocol) access to logs with the helpful info. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From marsh@extendedsubset.com Mon Jun 18 09:21:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E3021F8726 for ; Mon, 18 Jun 2012 09:21:11 -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 oJw+hFwSPLZ5 for ; Mon, 18 Jun 2012 09:21:10 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 211FB21F871A for ; Mon, 18 Jun 2012 09:21:10 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SgehR-00052B-HH; Mon, 18 Jun 2012 16:21:09 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9410860C1; Mon, 18 Jun 2012 16:21:08 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19qY5xmpxpBgB0AbWDKZMdKgyWjV/e3BAk= Message-ID: <4FDF5573.3090009@extendedsubset.com> Date: Mon, 18 Jun 2012 11:21:07 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jeffrey Schiller References: <4A50B48D-7686-40A9-A089-7B08A8CDB741@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 16:21:11 -0000 On 06/18/2012 08:18 AM, Jeffrey Schiller wrote: > > But there are ways to thwart this attack somewhat. For example if > someone provides a different invalid username say three times in a > row, start returning "no such user" for all attempts, including ones > where the user *is* correct and maybe even the password. How do we know it's the same "someone", in a way that an attacker can't fool? I don't think we can. Password-based login from the server perspective generally works like: "A pseudonymous remote party has established an ephemeral session with us. If the remote party demonstrates knowledge of Alice's username and Alice's password, then this party is Alice and the session is upgraded to a longer-lived 'login' session." But legitimate users mistype their passwords all the time, so we can't assume the inverse: "If this party fails to demonstrate knowledge of Alice's username and password, then the remote party is not Alice." If the password check fails, we know next to nothing about the identity of the remote party. We can log the source IP and port, but those can easily be spoofed. - Marsh From david.black@emc.com Mon Jun 18 10:13:27 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69BF21F8627 for ; Mon, 18 Jun 2012 10:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 Cgjoz4pCOAWQ for ; Mon, 18 Jun 2012 10:13:27 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B2DA121F86EB for ; Mon, 18 Jun 2012 10:13:23 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5IHDKeK009408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 13:13:21 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 18 Jun 2012 13:13:09 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5IHD5WX014252; Mon, 18 Jun 2012 13:13:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Mon, 18 Jun 2012 13:13:04 -0400 From: To: , Date: Mon, 18 Jun 2012 13:13:03 -0400 Thread-Topic: [saag] Error Handling & Security Thread-Index: Ac1NVUNtUIKCi/FHTcaTZDFpbS6wJwAHUk2w Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208C13FD3@MX15A.corp.emc.com> References: <4A50B48D-7686-40A9-A089-7B08A8CDB741@gmx.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 17:13:28 -0000 Of course the classic example of how not to do this was the Tenex password error returns. Tenex did a character-by-character comparison of the provided password with a correct one and would return a page fault error if it couldn't access the next character. The result enabled a linear complexity brute force attack on passwords. For example, if the attacker already know the first 3 characters, the next guess at the 4th character can be checked by positioning the password in memory so that access to the 5th character causes a page fault error, because the result is: - Bad password error: guess is wrong (4th character check failed, and Tenex did not try to access 5th character). - Page fault error: guess is right (4th character check passed because Tenex tried to access the 5th character). I believe the general principle here is that error returns from an authentication protocol should not reveal internal state information on where/how the authentication failed. The username/password discussion below is an example of possibly revealing a little bit of internal state (did the user check pass?). As Jeff notes, a risk analysis of the implications of exposing that info is appropriate. FWIW, a good fix for the Tenex problem is to copy the entire password into the OS before checking any of it, so that a page fault error doesn't reveal anything useful (application already has other ways to know whether a particular area of memory will vs. won't cause a page fault error). Thanks, --David > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of > Jeffrey Schiller > Sent: Monday, June 18, 2012 9:18 AM > To: Hannes Tschofenig > Cc: saag@ietf.org > Subject: Re: [saag] Error Handling & Security >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On Mon, Jun 18, 2012 at 7:59 AM, Hannes Tschofenig > wrote: > > When I was student (a little while ago) I was always told that you > > do not want to provide an attacker with additional information, > > including information that is returned in error responses. This > > specifically had an impact on the error handling procedures for > > authentication protocols. > > > > For end users and developers it is obviously better to offer more > > information to let them figure out what had gone wrong. > > > > So, there seems to be a conflict. >=20 > I believe the answer depends a lot on context and risk. Ask yourself > the question: "If I give a 'useful' answer here how will I be > empowering an attacker, what will they be able to do?" >=20 > Let's consider the simple and obvious case of user login. If you say > "username or password incorrect" [1], then you are divulging little > information, but a legitimate user won't know which part she got > wrong. On other hand if you say "no such user", then you have provided > some small information to the attacker. The attacker can then use your > login procedure as an Oracle to determine whether or not an account > exists. >=20 > But there are ways to thwart this attack somewhat. For example if > someone provides a different invalid username say three times in a > row, start returning "no such user" for all attempts, including ones > where the user *is* correct and maybe even the password. >=20 > Now three may not be the correct threshold. You want to set it high > enough that you don't confuse legitimate users, but low enough that > your login procedure cannot be used as a good Oracle. [2] >=20 > So my point is that you have to look at the trade-offs involved in > each situation and see if there is something you can do that preserves > usefulness for legitimate users while thwarting attackers. >=20 > -Jeff >=20 > [1] We'll ignore the issue of whether or not passwords are a good > authentication technology :-) > [2] And in some situations even one "no such user" answer is not > good. Consider the case of the porn site that uses e-mail > addresses as login names. If you provide "no such user" only in > the case where no such user really exists, then I can run your > email address by their login procedure to see if you are a > customer. Here the "harm" isn't compromising the site, but > compromising the user :-) [This isn't original to me, I read > about this cute possibility on-line, but I forget where] >=20 > - -- > _______________________________________________________________________ > Jeffrey I. Schiller > Information Services and Technology > Massachusetts Institute of Technology > 77 Massachusetts Avenue =A0Room E17-110A > Cambridge, MA 02139-4307 > 617.253.0161 - Voice > jis@mit.edu > http://jis.qyv.name > _______________________________________________________________________ >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iD8DBQFP3ypz8CBzV/QUlSsRApEOAKD0F2OJtIOHGjav6ygSqW3fCdUcLQCeOx5s > ONVLo5w/jUh97gHWQHUwjLk=3D > =3Do828 > -----END PGP SIGNATURE----- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hannes.tschofenig@gmx.net Tue Jun 19 12:33:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6E611E816A for ; Tue, 19 Jun 2012 12:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 7haGTJ7oTU-6 for ; Tue, 19 Jun 2012 12:33:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D290611E8116 for ; Tue, 19 Jun 2012 12:33:45 -0700 (PDT) Received: (qmail invoked by alias); 19 Jun 2012 19:33:44 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp035) with SMTP; 19 Jun 2012 21:33:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19zZJde17xzzFarM1JQ/5w3H/CsQsWDariAu9kQZW uSQw6cPUgEewCv Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 19 Jun 2012 22:33:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> References: To: Peter Gutmann X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 19:33:47 -0000 I guess I need to provide a bit of additional background for my = question.=20 In the OAuth working group folks are currently arguing that they do not = want to provide more detailed error responses in protocol exchanges or = in some cases no error message at all (even an error happened) -- = essentially being silent.=20 The argument that this is good for security but while I agree that one = needs to be careful about the information that is being provided back to = the client in case of an error I still see value in providing more = detailed error response.=20 As such, this is a bit unrelated to the question of what debug level is = currently enabled at the client software or what specifically is shown = to the user.=20 Without any information from the server (in case of an error) the client = software can obviously only guess what happens.=20 Ciao Hannes On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote: > Hannes Tschofenig writes: >=20 >> Experience or views from others? >=20 > I've been recommending that you make it a debug option that has to be > explicitly enabled, that adds extra noise to the protocol (e.g. an SSH = banner) > to make it obvious that it's enabled, and that turns itself off again = after a > set time or number of protocol runs. >=20 > Peter. From mcgrew@cisco.com Tue Jun 19 13:08:18 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17E311E80FC for ; Tue, 19 Jun 2012 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 UATHCC9GADZG for ; Tue, 19 Jun 2012 13:08:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D812A11E8098 for ; Tue, 19 Jun 2012 13:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2154; q=dns/txt; s=iport; t=1340136498; x=1341346098; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1Gj1ZDDsjitDkDq7YD6EInQpzlbKGbVy4vV7jjxElrM=; b=cBjjg9pe5LrSao8hEZ2wrCp6oQPuu9pVEQrl/32dazkeBeD8Nzj9BQZU 26XWjzAOCt1Y0aiFmt4ourpvBF0CCTlLvkEe9ZhzS8QZLhGY+XDBZoT27 7uWRUQ9Ug81PHPd7kjlddEzeVD64ADCCL1v3JHQ2kcYKvlTV8U6ybYZ/H 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAETb4E+tJV2c/2dsb2JhbABFtWyBB4IYAQEBAwEBAQEPASc0CwULCxguJzAGEyKHWwMGBQuZFKA3BIpMY4U5YAOVJY4XgWaCfA X-IronPort-AV: E=Sophos;i="4.75,800,1330905600"; d="scan'208";a="93893286" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jun 2012 20:08:17 +0000 Received: from rtp-mcgrew-8912.cisco.com (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5JK8G3F003399; Tue, 19 Jun 2012 20:08:16 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David McGrew In-Reply-To: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> Date: Tue, 19 Jun 2012 16:08:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <041792A1-26A0-4607-AF2C-4273D415BCD5@cisco.com> References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 20:08:19 -0000 Hi Hannes, On Jun 19, 2012, at 3:33 PM, Hannes Tschofenig wrote: > I guess I need to provide a bit of additional background for my = question.=20 >=20 > In the OAuth working group folks are currently arguing that they do = not want to provide more detailed error responses in protocol exchanges = or in some cases no error message at all (even an error happened) -- = essentially being silent.=20 >=20 > The argument that this is good for security but while I agree that one = needs to be careful about the information that is being provided back to = the client in case of an error I still see value in providing more = detailed error response.=20 >=20 > As such, this is a bit unrelated to the question of what debug level = is currently enabled at the client software or what specifically is = shown to the user.=20 >=20 > Without any information from the server (in case of an error) the = client software can obviously only guess what happens.=20 >=20 this is an interesting question. As I am sure that you already know, = crypto should be "atomic", that is, the error messages returned from = cryptographic operations should not give details about what went wrong = in the crypto processing (such as padding errors, decoding errors, and = the like). What is less clear are the other error messages that would = give out information such as which security options are actually in = effect. Are the (potential) error messages listed/documented somewhere? David > Ciao > Hannes >=20 >=20 > On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote: >=20 >> Hannes Tschofenig writes: >>=20 >>> Experience or views from others? >>=20 >> I've been recommending that you make it a debug option that has to be >> explicitly enabled, that adds extra noise to the protocol (e.g. an = SSH banner) >> to make it obvious that it's enabled, and that turns itself off again = after a >> set time or number of protocol runs. >>=20 >> Peter. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From david.black@emc.com Tue Jun 19 13:13:14 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B28511E80F5 for ; Tue, 19 Jun 2012 13:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 N9WJGEVIMvUi for ; Tue, 19 Jun 2012 13:13:13 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9486911E80B3 for ; Tue, 19 Jun 2012 13:13:13 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5JKD5ff020865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 16:13:10 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 19 Jun 2012 16:12:43 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5JKCZf3005447; Tue, 19 Jun 2012 16:12:43 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Tue, 19 Jun 2012 16:11:00 -0400 From: To: Date: Tue, 19 Jun 2012 16:10:59 -0400 Thread-Topic: [saag] Error Handling & Security Thread-Index: Ac1OUoWxKKWpyO5uToWv5x9D8CneRwAAvZ0w Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208C14227@MX15A.corp.emc.com> References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> In-Reply-To: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 20:13:14 -0000 Hannes, It's hard to say anything concrete without more details. For example, it's= always good to report syntax errors detected before security processing (e.g., rec= ipient can't extract the authentication request arguments/parameters from what was= received). At the other extreme, there are situations where a response is never a good= idea - one example is that IKEv2 specifies that an Informational message sent with= out cryptographic protection (e.g., to tell a sender that it needs to forget ab= out an IKEv2 SA because there's no state for it at the receiver) MUST NOT be respo= nded to. I think it comes down to looking at the details of "value in providing more detailed error response" in conjunction with "be careful about the informat= ion that is being provided back to the client", i.e., risk analysis as previous= ly noted. Thanks, --David > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of H= annes > Tschofenig > Sent: Tuesday, June 19, 2012 3:34 PM > To: Peter Gutmann > Cc: saag@ietf.org > Subject: Re: [saag] Error Handling & Security >=20 > I guess I need to provide a bit of additional background for my question. >=20 > In the OAuth working group folks are currently arguing that they do not w= ant > to provide more detailed error responses in protocol exchanges or in some > cases no error message at all (even an error happened) -- essentially bei= ng > silent. >=20 > The argument that this is good for security but while I agree that one ne= eds > to be careful about the information that is being provided back to the cl= ient > in case of an error I still see value in providing more detailed error > response. >=20 > As such, this is a bit unrelated to the question of what debug level is > currently enabled at the client software or what specifically is shown to= the > user. >=20 > Without any information from the server (in case of an error) the client > software can obviously only guess what happens. >=20 > Ciao > Hannes >=20 >=20 > On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote: >=20 > > Hannes Tschofenig writes: > > > >> Experience or views from others? > > > > I've been recommending that you make it a debug option that has to be > > explicitly enabled, that adds extra noise to the protocol (e.g. an SSH > banner) > > to make it obvious that it's enabled, and that turns itself off again a= fter > a > > set time or number of protocol runs. > > > > Peter. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From yaronf.ietf@gmail.com Tue Jun 19 21:40:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A90B21F86BE for ; Tue, 19 Jun 2012 21:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 DOpoZhCy8vkc for ; Tue, 19 Jun 2012 21:40:41 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C815321F86B9 for ; Tue, 19 Jun 2012 21:40:40 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4836223wgb.13 for ; Tue, 19 Jun 2012 21:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xAjuhN98UTnE4jPXFga+WeIJgdYP00XvuI+ym5RqTFk=; b=s9eTLukHhcDIOfZaEJ9ZN+f0TmxYfRawUzWSXDsESnDdzButL8B85760XfbgHQTlRB qAjRVkeg7m/l29qvokR5xmJI/TcG9UsnIXRC0NMW1MikqKAVJ0nqcrgWZVr1x3apn4NJ T/j4aU1V26Q4EHDRKMRo0P8qeXyW2DCVW1DQgDXeRqzzUXES1n7nRJ/o23Mh3wwdlkSD jPKBRPgYyleyEI6humP5Kxl4QjDTxsnyTmCz7ZbLC1CJTCFddGXX0BfWCQYsk9V9yNXj dKb2ojevsJ6UyFnJW6jxpYODGVudXZk9SaNyJ/70lorAP3HJ+0wQc1+xvA+GwmWgVo6G K4uQ== Received: by 10.216.19.195 with SMTP id n45mr11389988wen.69.1340167239667; Tue, 19 Jun 2012 21:40:39 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-161-38.red.bezeqint.net. [79.176.161.38]) by mx.google.com with ESMTPS id eb8sm36684010wib.11.2012.06.19.21.40.38 (version=SSLv3 cipher=OTHER); Tue, 19 Jun 2012 21:40:38 -0700 (PDT) Message-ID: <4FE15444.2040100@gmail.com> Date: Wed, 20 Jun 2012 07:40:36 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> In-Reply-To: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 04:40:42 -0000 Hi Hannes, One factor in this decision is the distinction between end-user errors (these errors that would benefit the end user) vs. developer errors. The trade-off between helpfulness and security should be different for the two types. For many protocols the only useful end-user error is "authentication failed" (of course with better wording for the intended audience). In some case "authorization failed" is also useful - you know then that you need to ask your system administrator for additional permissions. In the case of end-user errors my personal preference is for the most informative response possible. For example: "3 more tries before we lock you out of your account". On the other hand, we can be more stingy with indications that are only useful to a developer. Presumably the detailed errors are sent to an internal log (maybe optionally, to prevent timing attacks and DoS). And developers should have the option to approach the service owner directly to resolve interoperability issues. Thanks, Yaron On 06/19/2012 10:33 PM, Hannes Tschofenig wrote: > I guess I need to provide a bit of additional background for my question. > > In the OAuth working group folks are currently arguing that they do not want to provide more detailed error responses in protocol exchanges or in some cases no error message at all (even an error happened) -- essentially being silent. > > The argument that this is good for security but while I agree that one needs to be careful about the information that is being provided back to the client in case of an error I still see value in providing more detailed error response. > > As such, this is a bit unrelated to the question of what debug level is currently enabled at the client software or what specifically is shown to the user. > > Without any information from the server (in case of an error) the client software can obviously only guess what happens. > > Ciao > Hannes > > > On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote: > >> Hannes Tschofenig writes: >> >>> Experience or views from others? >> >> I've been recommending that you make it a debug option that has to be >> explicitly enabled, that adds extra noise to the protocol (e.g. an SSH banner) >> to make it obvious that it's enabled, and that turns itself off again after a >> set time or number of protocol runs. >> >> Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From bkihara.l@gmail.com Wed Jun 20 02:09:59 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3665A21F8705 for ; Wed, 20 Jun 2012 02:09:59 -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 bxZjilMW6aJF for ; Wed, 20 Jun 2012 02:09:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66B6921F8702 for ; Wed, 20 Jun 2012 02:09:58 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4212658vcq.31 for ; Wed, 20 Jun 2012 02:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Rz/WIQov+e0LJ985IWJBw/e3nkV9ylzGJacTfZzxE0=; b=oSdOwg/xUH+EnDZv/gMaSSLSdE2imrhYGC3mmc3NMWppryXWFOTrOr+EqNlFe29B0y UbDDPinY5H0pAdGpPptKFd52VPjlxJvk3ctXIhOHY/5celrT+XoJiQTTdKnmm+qxHV4U 3qi14RnJl9FAI9RyTuekucFuy9QnDSve4GLa21pvs8RHYduB/CLCsRW99tqObfcDcJ1P V8nV9DHQOReL/QhhvxZT6RCiZAZ/9Bxqs/8a/U7VURlMlNQRUN0EvvaIgHRU1AwKXvE3 QzpNv872oN3LGXYDTBynIvCg1drnN5PlS8ncGfIFfEYkmr1axUTrwdGAyNzc5gfLr1Bq gW9Q== MIME-Version: 1.0 Received: by 10.52.35.66 with SMTP id f2mr4030398vdj.31.1340183397910; Wed, 20 Jun 2012 02:09:57 -0700 (PDT) Received: by 10.220.71.202 with HTTP; Wed, 20 Jun 2012 02:09:57 -0700 (PDT) In-Reply-To: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> Date: Wed, 20 Jun 2012 18:09:57 +0900 Message-ID: From: "KIHARA, Boku" To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 09:09:59 -0000 Hannes, I think it depends on the policies of service providers, but having sandbox environments would be one solution. In a sandbox environment, verbose messages are returned so that developers can easily debug their products, without revealing any information about *real* users. Meanwhile servers in the real environment provide little or no information about errors to prevent attackers from getting helps. This method is somewhat costly, introducing the trade-off axis of cost. Cheers, Boku 2012/6/20 Hannes Tschofenig : > I guess I need to provide a bit of additional background for my question. > > In the OAuth working group folks are currently arguing that they do not want to provide more detailed error responses in protocol exchanges or in some cases no error message at all (even an error happened) -- essentially being silent. > > The argument that this is good for security but while I agree that one needs to be careful about the information that is being provided back to the client in case of an error I still see value in providing more detailed error response. > > As such, this is a bit unrelated to the question of what debug level is currently enabled at the client software or what specifically is shown to the user. > > Without any information from the server (in case of an error) the client software can obviously only guess what happens. > > Ciao > Hannes > > > On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote: > >> Hannes Tschofenig writes: >> >>> Experience or views from others? >> >> I've been recommending that you make it a debug option that has to be >> explicitly enabled, that adds extra noise to the protocol (e.g. an SSH banner) >> to make it obvious that it's enabled, and that turns itself off again after a >> set time or number of protocol runs. >> >> Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From jhutz@cmu.edu Wed Jun 20 08:55:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6542821F86CF for ; Wed, 20 Jun 2012 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IN9wALkFTT5 for ; Wed, 20 Jun 2012 08:55:11 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id C25FC21F86DB for ; Wed, 20 Jun 2012 08:55:11 -0700 (PDT) Received: from [192.168.33.131] (c-67-165-85-247.hsd1.pa.comcast.net [67.165.85.247]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q5KFt2EZ002158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2012 11:55:03 -0400 (EDT) From: Jeffrey Hutzelman To: Hannes Tschofenig In-Reply-To: <23079_1340134430_q5JJXmLl010948_15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> References: <23079_1340134430_q5JJXmLl010948_15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 20 Jun 2012 11:55:03 -0400 Message-ID: <1340207703.3279.530.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 15:55:12 -0000 On Tue, 2012-06-19 at 22:33 +0300, Hannes Tschofenig wrote: > I guess I need to provide a bit of additional background for my question. > > In the OAuth working group folks are currently arguing that they do not > want to provide more detailed error responses in protocol exchanges or > in some cases no error message at all (even an error happened) -- > essentially being silent. This seems a bit silly. This is almost entirely a policy decision, and you're attempting to inform protocol design by asking what the policy should be instead of what policies are possible. The protocol spec should not mandate a particular level of error reporting (or lack thereof); that is up to the operator. My advice: provide a mechanism for reporting errors and for doing so with the level of detail necessary for actually resolving problems. Don't mandate that the error-reporting mechanism be used, except in cases where it is needed to make the protocol work. But, don't prohibit reporting detailed error information either, except in cases where doing so would directly break the security of the protocol. Finally, _do_ make sure the security considerations include a discussion of the tradeoffs in error reporting. -- Jeff From mcr@sandelman.ca Wed Jun 20 10:29:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2060621F875D for ; Wed, 20 Jun 2012 10:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 MvAwobKe2wOP for ; Wed, 20 Jun 2012 10:29:20 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 49F0021F8745 for ; Wed, 20 Jun 2012 10:29:19 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 963338F0B; Wed, 20 Jun 2012 13:26:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B8FFD98C2E; Wed, 20 Jun 2012 13:29:16 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id ACD0E98182; Wed, 20 Jun 2012 13:29:16 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 20 Jun 2012 13:29:16 -0400 Message-ID: <14494.1340213356@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Fri, 22 Jun 2012 08:39:17 -0700 Cc: saag@ietf.org Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 17:29:21 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Hannes" =3D=3D Hannes Tschofenig writes: Hannes> The argument that this is good for security but while I Hannes> agree that one needs to be careful about the information Hannes> that is being provided back to the client in case of an Hannes> error I still see value in providing more detailed error Hannes> response.=20=20 It's a bogus argument to me. Security has to work be secure. If the protocol is too hard to debug, it will get turned off, and the result is that an inferior and less secure protocol will be used. In this case, this means storing access passwords in the clear in supplicant web servers. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT+IIbIqHRg3pndX9AQIrIgQArCqgBkDtDfpVx9SJvvs40kpYGKMT6TI3 HpwXCE3vNxCCas0rpdiKzvK/Z8R91leHg3QWYSZRjNIsrvPmOh2bZwpv1Inec2aK PTQZ82i59/EjpmK2Hdn37cYa2t8xm3Z5iwSQgNIBmiVByY7EZA79WArVCF528UuY px8PKyTutZ8= =+wrQ -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Jun 20 13:38:25 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D0A21F85E3 for ; Wed, 20 Jun 2012 13:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 YaFl5A0qcKwY for ; Wed, 20 Jun 2012 13:38:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F3B0721F85E0 for ; Wed, 20 Jun 2012 13:38:24 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id C18818F0B for ; Wed, 20 Jun 2012 16:35:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4710598C2E; Wed, 20 Jun 2012 16:38:21 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 39E4798182 for ; Wed, 20 Jun 2012 16:38:21 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> References: <15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 20 Jun 2012 16:38:20 -0400 Message-ID: <18254.1340224700@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Fri, 22 Jun 2012 08:39:17 -0700 Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 20:38:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Hannes" =3D=3D Hannes Tschofenig writes: Hannes> The argument that this is good for security but while I Hannes> agree that one needs to be careful about the information Hannes> that is being provided back to the client in case of an Hannes> error I still see value in providing more detailed error Hannes> response.=20=20 It's a bogus argument to me. Security has to work be secure. If the protocol is too hard to debug, it will get turned off, and the result is that an inferior and less secure protocol will be used. In this case, this means storing access passwords in the clear in supplicant web servers. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT+IIbIqHRg3pndX9AQIrIgQArCqgBkDtDfpVx9SJvvs40kpYGKMT6TI3 HpwXCE3vNxCCas0rpdiKzvK/Z8R91leHg3QWYSZRjNIsrvPmOh2bZwpv1Inec2aK PTQZ82i59/EjpmK2Hdn37cYa2t8xm3Z5iwSQgNIBmiVByY7EZA79WArVCF528UuY px8PKyTutZ8= =+wrQ -----END PGP SIGNATURE----- --=-=-=-- -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From mcr@sandelman.ca Wed Jun 20 13:38:32 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2721F85E3 for ; Wed, 20 Jun 2012 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 NRXxet19p3V0 for ; Wed, 20 Jun 2012 13:38:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E18B221F85DF for ; Wed, 20 Jun 2012 13:38:31 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 2D2088F0B for ; Wed, 20 Jun 2012 16:35:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E439498C2E; Wed, 20 Jun 2012 16:38:30 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DE55F98182 for ; Wed, 20 Jun 2012 16:38:30 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <1340207703.3279.530.camel@destiny.pc.cs.cmu.edu> References: <23079_1340134430_q5JJXmLl010948_15FC0C46-8C18-4C77-87BF-470BFC964187@gmx.net> <1340207703.3279.530.camel@destiny.pc.cs.cmu.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 20 Jun 2012 16:38:30 -0400 Message-ID: <18296.1340224710@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Fri, 22 Jun 2012 08:39:17 -0700 Subject: Re: [saag] Error Handling & Security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 20:38:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Jeffrey" =3D=3D Jeffrey Hutzelman writes: Jeffrey> This seems a bit silly. This is almost entirely a policy Jeffrey> decision, and you're attempting to inform protocol design Jeffrey> by asking what the policy should be instead of what Jeffrey> policies are possible. The protocol spec=20 Jeffrey> should not mandate a particular level of error reporting (or l= ack Jeffrey> thereof); that is up to the operator. +1 =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT+II4YqHRg3pndX9AQK4JgP/TBGfNxviJIM8RHKgRTq7dphGbABdBr89 pFktRZJs81y/XZVMpdKApFmf59UHQ9bbo+y+ZkM3DwKz6GEGVzAEcPqfhomRBhh6 Rz+v1yHn3yK881JWSoS3+0myo+7XpsQ7Rf3kvO4eM7kcBQTQh93Yz/djJSlQPcOW jj2TNjCPjcU= =cv71 -----END PGP SIGNATURE----- --=-=-=-- -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From hallam@gmail.com Mon Jun 25 13:35:56 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5F221F8548 for ; Mon, 25 Jun 2012 13:35:56 -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 rIKErepQIHAQ for ; Mon, 25 Jun 2012 13:35:55 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1CB21F847A for ; Mon, 25 Jun 2012 13:35:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3581976ghb.31 for ; Mon, 25 Jun 2012 13:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JDm1jpVKIxE2Kq8rDIU0m+oqzN7bdcQnVnttnl4AI1s=; b=uD+awC3DdkYse0t/TX88dm3hEd6LwxwHmKgMiDsfXXkvXTFodZGTEo1i3N4D5Cv2/T MiLzeX2m54EdPd8sSu3JcawFdep0XIa7FKNBVA1VAihEO04KTwSBnl5RLxyZhpAJ10WD QtBQzFQEoKegWjbnZIyiqBtpi/Y9EN29gM0ohL2wAQ0PMSuOxdVW0iequUEmLalN6fbM na8wqxeDTIQJrqF/EjuCYEC4g3qpznzPJUMHjyb8a23CSMpXesLO5e2785xqh4iHFw41 qwynfG1XIBNF2bBCS/2L9npYZI5D9ClVAcwSmkCqDwbDbLkUSRnVsRjbp5+XUsOucXaD NWxg== MIME-Version: 1.0 Received: by 10.236.114.137 with SMTP id c9mr14846606yhh.46.1340656554640; Mon, 25 Jun 2012 13:35:54 -0700 (PDT) Received: by 10.236.116.68 with HTTP; Mon, 25 Jun 2012 13:35:54 -0700 (PDT) Date: Mon, 25 Jun 2012 16:35:54 -0400 Message-ID: From: Phillip Hallam-Baker To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 20:35:56 -0000 An issue that appears to cause a lot of controversy out in WGs is the issue of whether a security requirement should be stated as a SHOULD or a MUST. While it may appear obvious that a specification should prohibit a bad practice, I now think this is the wrong approach. Security is a balance of concerns that are often in conflict. When the only concern is confidentiality, the best approach in cases of ambiguity is usually going to be to refuse any action that might lead to disclosure. But this approach is inevitably in conflict when service availability is the prime concern. When a specification says MUST in relation to a security concern it most often says 'MUST refuse' or some other action that turns into 'MUST break'. These are not decisions that the specification writer is in a position to judge. The only party that can make these judgments are the application developers who understand the context in which the application is to be deployed. This is not an abstract concern. In recent months we have had two cases where IETF working groups have take one approach and industry has taken the other and in both cases the point at issue was whether a specification should provide security advice or whether conformance should require a specific security policy. I don't think anyone is going to deploy DANE on a large scale with the MUST reject feature implemented the way that the authors imagine. Unless we have a means for automatically updating the DANE records to the SSL service that the relate to the data in DANE records is just not going to be accurate enough for direct client enforcement anyway. Nobody uses DKIM policy records without some form of curator being involved, why expect DANE to be any different. On PKIX we have nonsense on stilts. The industry wants to use a feature of X.509 but the PKIX specification mandates that this can only be used if marked so as to mandate rejecting backwards compatibility with deployed products (including Safari). This seems a rather obvious shortcoming in the specification to me. But at root the problem is that nobody with sense is going to be looking to a consensus based process for direction on security policy. A consensus based process can certainly advise but only stakeholders can make an actual decision. -- Website: http://hallambaker.com/ From nico@cryptonector.com Mon Jun 25 14:16:07 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB32211E80A1 for ; Mon, 25 Jun 2012 14:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=-1.571, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 3d99wIcPQK-Y for ; Mon, 25 Jun 2012 14:16:06 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50C11E808C for ; Mon, 25 Jun 2012 14:16:06 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 5420A50807F for ; Mon, 25 Jun 2012 14:16:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=m7FoIScNXzhpVz955WCLQ ryPPXuZLOcGSAChz5tYRqhXsj6zJ1anqX7OYwpCgJivKb63ahe1Q8S6kS0MfSRVq 3rsav4oAYIWzvq4KfMcbNToPCniJbaXoDZQy7qfjPgnhD3VmW4AVh/DMCD41XI55 Yarem900asu9zHwPHg27Ag= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VSsxjzc9bNiDK1+OXqyx jwVoi8Y=; b=NVgDAevOX8fCh7goioZbLO70+RNyZ3rBuMSN1G9VsoBkwckzH1Vr Y2n1SkLXYj1zTxf6q57ggKKVhRkBmuDqhjc0qRpoFint/H4TpzhDf+tdyHabmBQN KorknkxHqwjF8qUHBg4J8A24xVweSGJltUXQpfXqye/u7bqjtwlO6mc= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 3480150807B for ; Mon, 25 Jun 2012 14:16:06 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7177005pbc.31 for ; Mon, 25 Jun 2012 14:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.232.232 with SMTP id tr8mr44414342pbc.73.1340658965761; Mon, 25 Jun 2012 14:16:05 -0700 (PDT) Received: by 10.142.165.6 with HTTP; Mon, 25 Jun 2012 14:16:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 16:16:05 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 21:16:08 -0000 On Mon, Jun 25, 2012 at 3:35 PM, Phillip Hallam-Baker wrote: > On PKIX we have nonsense on stilts. The industry wants to use a > feature of X.509 but the PKIX specification mandates that this can > only be used if marked so as to mandate rejecting backwards > compatibility with deployed products (including Safari). This seems a > rather obvious shortcoming in the specification to me. But at root the > problem is that nobody with sense is going to be looking to a > consensus based process for direction on security policy. A consensus > based process can certainly advise but only stakeholders can make an > actual decision. I assume you mean Name Constraints. Too much deployed code doesn't implement them but still understands criticality (i.e., breaks in the presence of critical name constraints). Breaking interop is the right thing to do when you're only just getting started deploying the protocol. Critical name constraints would have been great to have seen deployed way, way bak in the mid-90s. But I'm not endorsing -not yet- non-critical name constraints. It'd be useful to first understand what it'd take to get enough of the RPs (browsers, mostly) fixed, and how much time that would take, so we can understand how long we can expect to see critical extensions made non-critical. We've seen Google work hard with various vendors to make Google's TLS extensions workable, and granted, that's only servers, but in some cases TLS concentrators are harder to fix in the field than browsers (which nowadays self-update). Nico -- From nico@cryptonector.com Mon Jun 25 14:33:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23811E80A6 for ; Mon, 25 Jun 2012 14:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 u4Wckm6pwH5S for ; Mon, 25 Jun 2012 14:33:51 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id AC09E11E80A1 for ; Mon, 25 Jun 2012 14:33:51 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 2530C264070 for ; Mon, 25 Jun 2012 14:33:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=TQqT4uvOmTEOwVwyam4zt EWzh0CHGQRoyYzkgKZae2Aqd49q+TtyPqpXOypauVJQUdpOd75rR8BtYrON2L8VA 9TsZZPV3jHXSXBHVlTypZr8ThzdT1htxyBG4naYaRtWpCofOCMDjcTQjR7PFKTtf MlwFehogrK9pcmndC00LE0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DWKb1nsLAt8UYkNm+9MD HZHg/GU=; b=S5CtzcoLyIBVmh2vDu6eA/z0UgwkLsV7/5oBg6CvjZLKrdrbBe2Y XA4ZcYUaSYgBOvYWXVA5Hokq+USUMjAwuOfmLNlR8c5BCcG3RIxPDhVMP+2Ax2qh Qab6LGj7jbgyDbOzlDRcgjEQW6fYlh+uCVzZCszq85VO9k2N2hEhw7M= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 0912F26404E for ; Mon, 25 Jun 2012 14:33:51 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7194626pbc.31 for ; Mon, 25 Jun 2012 14:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.222.40 with SMTP id qj8mr43833859pbc.139.1340660030663; Mon, 25 Jun 2012 14:33:50 -0700 (PDT) Received: by 10.142.165.6 with HTTP; Mon, 25 Jun 2012 14:33:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 16:33:50 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 21:33:52 -0000 Thinking more about it: - I'd say that any CA wishing to use non-critical name constraints (which you didn't propose, but which I assume is what you're getting at) must be auditable, and its sub-CAs must be auditable -- in real-time. And they must issue postdated certs only, with enough time to expect the public to audit them (say, a few days, or at least a few hours). And the sub-CAs must use HSMs, and be setup by the CAs, ... - I'd like to see quantitative analyses of a) how much breakage we can expect to see if CAs deployed critical name constraints, b) how many users would be rendered vulnerable to MITM attacks by sub-CAs if CAs are allowed to issue sub-CA certs with non-critical name constraints. Also, it's not what the RFCs say, it's what browser/OS vendors are willing to allow into their trust anchor sets -- they are the enforcers, and there is no IETF police. Nico -- From nico@cryptonector.com Mon Jun 25 14:49:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E511E80B8 for ; Mon, 25 Jun 2012 14:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=-1.405, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 cPfO-MmKzLrq for ; Mon, 25 Jun 2012 14:49:36 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 80B8E11E808C for ; Mon, 25 Jun 2012 14:49:36 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 47EA6438079 for ; Mon, 25 Jun 2012 14:49:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=rKAgp77RQo96l7Q7tg46LBP7q5T7m+AVuxQ04dwdP6yN URQMw5ESWk3BaN6G0zJ02Eq3u1esT4nAHyto/YjjFP1Yf4tb+6R8Zfv2KZoW1SnI ua1rYEPHQU8doh6vHpoFkxpbsOEE2pyeCneXCo9pwyqP1O0RKdlanehX+yJh5AU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=zt2naoCHMUVZe1TTRZcmjeWNWIw=; b=PyTaK267sZW /rvSK4zNtYbQIzQ77AZ4WrWnh0XjG4G3aCAoPXLAlrUDfXy58r/J+aywynG/Xhrb vrEXcYuorhyyFT97e8cJg0IXI5q3OWrQ9di/yfypNfA3OVrxdrIplY8n3xU6j5EM HSaDhzeVXrFb0FViQu7YUMxZ53LbXlYQ= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 2D41D438072 for ; Mon, 25 Jun 2012 14:49:36 -0700 (PDT) Received: by dacx6 with SMTP id x6so5931772dac.31 for ; Mon, 25 Jun 2012 14:49:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.200.232 with SMTP id jv8mr43875945pbc.161.1340660975842; Mon, 25 Jun 2012 14:49:35 -0700 (PDT) Received: by 10.142.165.6 with HTTP; Mon, 25 Jun 2012 14:49:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 16:49:35 -0500 Message-ID: From: Nico Williams To: Yutaka OIWA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Sam Hartman , saag@ietf.org Subject: Re: [saag] On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 21:49:37 -0000 On Fri, Jun 15, 2012 at 7:38 PM, Yutaka OIWA wrote: Please excuse the time it took me to respond. I've been traveling. > 2012/6/12 Nico Williams : >> On Fri, Jun 8, 2012 at 9:14 PM, Yutaka OIWA wrote: > >> But I'm interested in why you want new authentication mechanisms at >> the HTTP layer (on the wire) that require more than one round trip. > > In a simple answer, we found that putting it in payload layer is > unnatural for our solution. =C2=A0It is not our design principle, but the= result of > our design analysis. I'm not sure what you mean by "unnatural". It'd be useful to explore that. If you mean that it's unnatural to require that applications implement the authentication protocol, then I agree (though I also think it's nice to have that option so that apps can do strong authentication with older HTTP stacks). If you mean that application-layer authentication is unnatural on the wire then I disagree vehemently. In fact, I think any HTTP-layer authentication scheme will be unnatural on the wire: HTTP is a one-round-trip, stateless protocol, but authentication protocols are mostly NOT one round-trip (or less). > Our foundational way of thinking is first to decide what problem will be = solved, > what solution can be used, how the communication will occur, and finally, > how these things are put on the wire, considering all benefits and > deficits there. > I think that we should not put any protocol-implementation > restrictions on the first priority > (software implementation/deployment issue is important). > > Our design considerations is now described in > http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals/MutualA= uth/LayeringDesigns That's quite lengthy, but it doesn't explain what's unnatural about my proposal. Or at least I'm not understanding it. > As I described in the above document, HTTP payload and HTTP headers are > isomorphic (in other words, exchangeable in design). =C2=A0However, if we= think of > imaginary (non-existing) protocol which we move the key exchange messages > of our Mutual authentication to the payload layer, we immediately see tha= t > it will not fit to real applications, will not fit our security > requirements, will introduce > unneeded complexities in both server and client sides, I don't immediately see that. You assert it, but you don't explain. > I strongly believe that, under such situation, we should not stick to > specific layering philosophies but we should choose the best > layering choices for each solution. I would agree, but you've not convinced me that we're in such a situation. Nico -- From turners@ieca.com Tue Jun 26 05:29:53 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D4A21F8617 for ; Tue, 26 Jun 2012 05:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 kfENwUDjBWGW for ; Tue, 26 Jun 2012 05:29:53 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.22.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6409B21F8615 for ; Tue, 26 Jun 2012 05:29:53 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id C9F80995C2E03; Tue, 26 Jun 2012 07:29:52 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id BF94C995C2DE3 for ; Tue, 26 Jun 2012 07:29:52 -0500 (CDT) Received: from [96.231.119.66] (port=34547 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SjUu0-0004d2-OH for saag@ietf.org; Tue, 26 Jun 2012 07:29:52 -0500 Message-ID: <4FE9AB40.4050106@ieca.com> Date: Tue, 26 Jun 2012 08:29:52 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:34547 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Call for SAAG presentation topics X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:29:53 -0000 Folks, Stephen and I are putting together the SAAG agendas for Vancouver. The agenda traditionally includes one or two invited presentations after the working group reports. We would appreciate submission of presentation topics that you believe would be of interest to the community. If you can identify an appropriate presenter (not necessarily yourself) that would be helpful. Thanks, spt From palmer@google.com Tue Jun 26 15:12:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DE421F845D for ; Tue, 26 Jun 2012 15:12:29 -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 OtEcIyM8pvb4 for ; Tue, 26 Jun 2012 15:12:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7EAD21F8450 for ; Tue, 26 Jun 2012 15:12:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so699861lbb.31 for ; Tue, 26 Jun 2012 15:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=+GvBw7MwgohFjPywuQ2Ouk8M164MUiHh0tKgCjElGN4=; b=FOkmWrk+GowXh/BA+CODQWBKDniaYuTZcfefVdKaZGulSc8gCQu1bPZGZuKi9T8hNI zpdnNlxDIyYc5Lj9Zl9EpckZb14xGqRkdNyfmyv0s1JITGxfmUzw7rcCI4R2n+xS6JxO YzJMQIug4FI75ai7Q+bNU8NlXfwMr2WEK0EzT+QL+gi6eoa5HYf2/ArVYxH90wRuEM4p fGcZrCuTcRcO3uFDo0TQiedp+vEpyhszN08NK8EX5luExaAWv1v+7oNJIbhyuylU6scf O+wduc0YP8xQOIikOupiqQAySGGWeqDdcqq+/LM87XoBSAn9lhM4cWo5msw6eugFs41l 3PsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=+GvBw7MwgohFjPywuQ2Ouk8M164MUiHh0tKgCjElGN4=; b=N7YnJYdK6IkWMZ+s8BDZ2AubgXFVccnxZ7rsxrItO1TMKpqJr/HZci20p166H7YvBQ +w46vVaZ4zJPdPWeAXKTYlp5lkviYVM3e0IXx8M/aBBrIGwCqVbC9v/DKX8j03KXJyCJ MlxEVP8BWQwTgucpey8CRNTvShDCoYjv7TaRpm0QlKLXgr0QIXYaUW/DpWvahtQpcjAS R/mUTfpuvsVV75VwmAOovEAStqqFfHRaGeNg1STRH9GqK77Y2HIO1Z3CoHz4A6of4iI4 A+Dmjt1enEyfyGY3AeyOamAVpbHn2XN8u+BF+cnEW9APilxUZShk26baX6uX9Kx0drBE 3IAw== Received: by 10.112.42.228 with SMTP id r4mr8231084lbl.4.1340748747877; Tue, 26 Jun 2012 15:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.42.228 with SMTP id r4mr8231074lbl.4.1340748747754; Tue, 26 Jun 2012 15:12:27 -0700 (PDT) Received: by 10.112.4.133 with HTTP; Tue, 26 Jun 2012 15:12:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 15:12:27 -0700 Message-ID: From: Chris Palmer To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQn3Lj4xJprARa5U7Krkh/sOVhsaDjwAyG7sfWEF9waFO1eLRYY4/FA5ViW/Yq20kK9kaIsFzfivcEN2Bn2Ct3jiZ9P84cH5pvn2tiV7tmHvmylFtBK04GLYkE5Ku8r3+gPRvfROyo5JbzsgbbZxnD0UFsO/RT6Q6g9WLAl81D7L8ETzNHA= Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:12:29 -0000 On Mon, Jun 25, 2012 at 2:33 PM, Nico Williams wrot= e: > Also, it's not what the RFCs say, it's what browser/OS vendors are > willing to allow into their trust anchor sets -- they are the > enforcers, and there is no IETF police. We (Google Chrome developers) want name constraints. Critical name constraints blow up enough clients that it's a deal-breaker. But imagine a client that says to itself, "The cert says these name constraints are non-critical =E2=80=94 presumably for backwards compat. But I'll treat them as critical, since I was implemented in late 2012 and my implementers knew that name constraints are spiffy." Fewer clients will explode upon seeing an unknown-but-critical extension. (Some clients will explode anyway, probably, but fewer; and we can much more reasonably call those clients buggy.) From stephen.farrell@cs.tcd.ie Tue Jun 26 15:20:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBECC11E809F for ; Tue, 26 Jun 2012 15:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 TEJXnl4sYBWD for ; Tue, 26 Jun 2012 15:20:29 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D302C11E8097 for ; Tue, 26 Jun 2012 15:20:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4D2F61715B2; Tue, 26 Jun 2012 23:20:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340749225; bh=LOt5LeQwvar2Ft aoPx4oXaMn+q8mcYAwnoBeEBZFZYs=; b=TWRQVD2tEpHH3HPZnDyVQyYJjlGNko nTFWr/HoLnYxmGd4v8vLmUra7GXHCTucmJF6grgzSfB75eMWFizkYSPtIZFMluWV K9WE9z/ihtETJLcVmI8x3lrnW2HkSH5kBy7DFpTYQ4juisltaDpwgNrFEOlimFgE hYtbwpCNTEeMrgcsTLDvB+kpT+4w6ozrFEVaYkxIYChNw60vMASNhZKX0jUdHuD7 L2vF6ZM1Kr4+4FJdWNuPP3w2zQC5nYYeVdZ/eXwOS70eAz7jyeaZg3+L32gmG/yJ uDzYLrGRsTTCOSyA+PSrKFfpO8Kxr3pFNa7M6eT2A9zLyQPYvDsa3/Yg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id uZ6WEf2Gr79M; Tue, 26 Jun 2012 23:20:25 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.10.105]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A39F317151B; Tue, 26 Jun 2012 23:20:24 +0100 (IST) Message-ID: <4FEA35A8.80201@cs.tcd.ie> Date: Tue, 26 Jun 2012 23:20:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Chris Palmer References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:20:30 -0000 Hi Chris, On 06/26/2012 11:12 PM, Chris Palmer wrote: > On Mon, Jun 25, 2012 at 2:33 PM, Nico Williams wrote: > >> Also, it's not what the RFCs say, it's what browser/OS vendors are >> willing to allow into their trust anchor sets -- they are the >> enforcers, and there is no IETF police. > > We (Google Chrome developers) want name constraints. Is that really the case? ISTM, that what you and others want is something very like, but is not, the existing NC extension. (That's been part of the problem with that discussion, some folks are making some bad arguments in a possibly good case.) But - I think that's a discussion for the pkix list. Phill's question is broader and different and probably more useful to discuss here. S > Critical name > constraints blow up enough clients that it's a deal-breaker. > > But imagine a client that says to itself, "The cert says these name > constraints are non-critical — presumably for backwards compat. But > I'll treat them as critical, since I was implemented in late 2012 and > my implementers knew that name constraints are spiffy." Fewer clients > will explode upon seeing an unknown-but-critical extension. (Some > clients will explode anyway, probably, but fewer; and we can much more > reasonably call those clients buggy.) > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From ekr@rtfm.com Tue Jun 26 15:25:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA111E80E2 for ; Tue, 26 Jun 2012 15:25:23 -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 gGMQ-OSSABtT for ; Tue, 26 Jun 2012 15:25:23 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E15FC11E80DF for ; Tue, 26 Jun 2012 15:25:22 -0700 (PDT) Received: by yenq13 with SMTP id q13so461884yen.31 for ; Tue, 26 Jun 2012 15:25:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=7V1ShcDuBDpICpc1XywSQiqjTCyhvax9zYesS8Km3+0=; b=Dg8j2sAhfh9SDM9aEFdifr4C/6+WxP6h55HNnw0vBnx8Wq2EtQM1SV72uUrdFGQ8qc Ew/bsjoNi5aJ9gr8gfXiugpgA2/kkJy7aC+NzDw0X1bj3PWJNtEJ6ZUt6Ne989rRMgZR 1aej4nAdO55yjGbeJx8ipPQBdhUR+DFFnuptzfn0sheo2HKERJ0lvfKgH5UbNyJEjeRw qq+vRetwamuAOmmUBcTVBZvvmBNDh7zzOpdn27IiNJ0P6OC1XT3DW1dGTpJ7er4DfhWe BlQ7KNdztNisLC+v7VvNUUh4vXX9G5tCFmem99n67EF9qndo2f+ZUFZeLYQtoL8rNjEs TWuA== Received: by 10.50.47.166 with SMTP id e6mr12679736ign.55.1340749522326; Tue, 26 Jun 2012 15:25:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.240.6 with HTTP; Tue, 26 Jun 2012 15:24:42 -0700 (PDT) X-Originating-IP: [2620:101:8003:300:5a55:caff:fef1:5a11] In-Reply-To: References: From: Eric Rescorla Date: Tue, 26 Jun 2012 15:24:42 -0700 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlMTy93le1vq9A/92HEZU3IlyLCV0D91Jwynl6sWZffKvGr8oIIwo7B5nIGxjM4KOKUre5x Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:25:23 -0000 On Tue, Jun 26, 2012 at 3:12 PM, Chris Palmer wrote: > On Mon, Jun 25, 2012 at 2:33 PM, Nico Williams wr= ote: > >> Also, it's not what the RFCs say, it's what browser/OS vendors are >> willing to allow into their trust anchor sets -- they are the >> enforcers, and there is no IETF police. > > We (Google Chrome developers) want name constraints. Critical name > constraints blow up enough clients that it's a deal-breaker. > > But imagine a client that says to itself, "The cert says these name > constraints are non-critical =97 presumably for backwards compat. But > I'll treat them as critical, since I was implemented in late 2012 and > my implementers knew that name constraints are spiffy." Fewer clients > will explode upon seeing an unknown-but-critical extension. (Some > clients will explode anyway, probably, but fewer; and we can much more > reasonably call those clients buggy.) Chris, I'm not sure I am following this. Are you suggesting that this hypothetical browser would recognize name constraints but not be able to process them? As I understand 5280, criticality applies how you process stuff you aren't able to process. -Ekr From nico@cryptonector.com Tue Jun 26 16:28:17 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CF611E80B5 for ; Tue, 26 Jun 2012 16:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 T71Psckp7dBK for ; Tue, 26 Jun 2012 16:28:16 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id B765511E809F for ; Tue, 26 Jun 2012 16:28:16 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 7BAD735005B for ; Tue, 26 Jun 2012 16:28:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=LzP2a17l72p6LWJ2b/63UCxGMDK3jJIYCHa5i0izUam9 ZxkhiGqX+aH5qDarWG3yt/+An2cQ3CdlOhF9nhCgUnfDuqhadOZxErtTyLFUsGJE obpTI2NKip7ccq+JEEXuCeu9gmjKjmosxNrPReKiPI/r7b+W7F2hI98azI6KM3Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ExJBxGwvMK0nSA7wiGR6HWzOGqk=; b=KLWRehu5LnJ +Fo8sJWDO3jvAsDmiWlpWtYcYAWqHaM7m5ljfk8s8yI7kH5BqcSpEeMvGS9KWGR5 V22R8rBwL0n28ZC/bejQGXUhicPL6cBL33gyNbsobCrXrF3wdhKN0I3K8pFKSzfK zcXqcx4MoMIxnKWCefGll07IboGTVVXg= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 6A982350058 for ; Tue, 26 Jun 2012 16:28:16 -0700 (PDT) Received: by dacx6 with SMTP id x6so545184dac.31 for ; Tue, 26 Jun 2012 16:28:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.130.67 with SMTP id oc3mr26322425pbb.18.1340753295918; Tue, 26 Jun 2012 16:28:15 -0700 (PDT) Received: by 10.142.165.6 with HTTP; Tue, 26 Jun 2012 16:28:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 18:28:15 -0500 Message-ID: From: Nico Williams To: Chris Palmer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 23:28:17 -0000 On Tue, Jun 26, 2012 at 5:12 PM, Chris Palmer wrote: > On Mon, Jun 25, 2012 at 2:33 PM, Nico Williams wr= ote: > >> Also, it's not what the RFCs say, it's what browser/OS vendors are >> willing to allow into their trust anchor sets -- they are the >> enforcers, and there is no IETF police. > > We (Google Chrome developers) want name constraints. Critical name We all should. Are you endorsing non-critical name constraints? Or just wishing you could use name constraints, and thinking that it may be possible to make them non-critical with very limited loss of security? (see below) > constraints blow up enough clients that it's a deal-breaker. Right. > But imagine a client that says to itself, "The cert says these name > constraints are non-critical =E2=80=94 presumably for backwards compat. B= ut > I'll treat them as critical, since I was implemented in late 2012 and > my implementers knew that name constraints are spiffy." Fewer clients > will explode upon seeing an unknown-but-critical extension. (Some > clients will explode anyway, probably, but fewer; and we can much more > reasonably call those clients buggy.) CAs issuing sub-CA certs with non-critical name constraints (NCNC?) would effectively be issuing MITM sub-CA certs. This can be mitigated, perhaps to the point of such practices being acceptable. I'd like to see a quantitative analysis of how many users would be rendered vulnerable to MITMing sub-CAs, for starters. If that number is small enough then one could argue that the remainder confer a sort of herd immunity on them, but it's not clear that that's correct. If vulnerable clients can be fingerprinted then the herd immunity argument is weakened since the only incentives left to not MITM vulnerable clients would be: getting caught via audits, or the number of vulnerable clients being so small that it's not worth the effort to MITM the few and far between that get exposed to an evil sub-CA. Nico -- From jis@mit.edu Tue Jun 26 20:12:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2766321F84B3 for ; Tue, 26 Jun 2012 20:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.744, 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 g-QPnnuQBZfr for ; Tue, 26 Jun 2012 20:12:20 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECF21F8484 for ; Tue, 26 Jun 2012 20:12:14 -0700 (PDT) X-AuditID: 1209190f-b7f306d0000008b4-7a-4fea7a0da366 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A4.EF.02228.D0A7AEF4; Tue, 26 Jun 2012 23:12:13 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q5R3CDtm023868 for ; Tue, 26 Jun 2012 23:12:13 -0400 Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (authenticated bits=0) (User authenticated as jis@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q5R3CBpr029051 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 26 Jun 2012 23:12:13 -0400 (EDT) Received: by obbwc20 with SMTP id wc20so860752obb.31 for ; Tue, 26 Jun 2012 20:12:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.152.73 with SMTP id uw9mr13158689obb.0.1340766731397; Tue, 26 Jun 2012 20:12:11 -0700 (PDT) Received: by 10.182.42.227 with HTTP; Tue, 26 Jun 2012 20:12:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 23:12:11 -0400 Message-ID: From: Jeffrey Schiller To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixCmqrMtb9crfYM9tPYsp/Z1MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuLTyNWvBfdmKqwc+MDUwLpboYuTkkBAwkbi38w0ThC0mceHe erYuRi4OIYF9jBL/Nl5ngXCOMEpM/7kRyrnNJLF40lNGkBYhgQqJbZP/soDYvAKCEidnPmGB iBdK3O66zgRhe0t07HwIFucUCJQ4efMR1Io3TBLLH28HG8QioCpxduMyoCIOoEEBEp/eaIKE hQUsJW60djCD2GwCKhLb3rWA2SJAux70TQKbySygI/Gu7wHzBEbBWUjOmIUktYCRaRWjbEpu lW5uYmZOcWqybnFyYl5eapGuiV5uZoleakrpJkZwWEry72D8dlDpEKMAB6MSD28Eyyt/IdbE suLK3EOMkhxMSqK8l8qBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4f+sC5XhTEiurUovyYVLS HCxK4rxXU276CwmkJ5akZqemFqQWwWRlODiUJHg9KoEaBYtS01Mr0jJzShDSTBycIMN5gIbr gtTwFhck5hZnpkPkTzEaczx7e+QGI8e0nhM3GIVY8vLzUqXEeRNBSgVASjNK8+CmwVLLK0Zx oOeEefNAqniAaQlu3iugVUxAqzg2vQBZVZKIkJJqYEw9kJEeUy15asbFpa5VhzoX5JzW7Pk+ y+VwUzVnafeVe5y2H6Rb8oKfKRzq3GLokvWwpk/+JrdRyupFtp+uCAbPWqu7mnVS6ETBHWxZ 0ydGf5B89+yIi/jKKwfWSSsc2FwZLSA027L1wZTZjcUMxx5ckdmVYH52w78/W7eY/xGPXvdo p5Wl238lluKMREMt5qLiRACxpY8OCAMAAA== Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 03:12:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Let's get back to Phill's main point which I believe is that implementers are in a much better position to understand the security trade-offs involved in a given deployment, then say the protocol designers. That as protocol designers, we shouldn't presume to understand all deployment environments and therefore should not preclude security "settings" (for lack of a better term) that may not make sense to us, but do make sense in some (unknown to us) context. Let me expand a bit on this and give some history (as a Security AD from 1994-2003, I have some history in my head!). A lot of the security area's "strictness" evolved in the mid 1990's when many (outside of the Security Area) folks in the IETF really didn't care much about security. Internet Security threats were mostly kids, not the organized crime and state actors that we see today. We used to have (still do?) a requirement that all RFCs have a "Security Considerations" section. The purpose of this requirement was to get folks to think through security issues. It was only partially successful. More people asked me "What weasel words should I put in the Security Considerations Section to get it approved" then asked me "How can we truly address security concerns in this protocol." My favorite situation involved the elevation of a protocol to DRAFT Standard. In order to become a DRAFT Standard, a protocol needed to have at least two independent implementations of all features of the protocol. Features that did not have independent implementations needed to be removed from the standard prior to elevation to DRAFT. So I was approached about removing all security from a protocol because well... there weren't two implementations of the security features and the document authors wanted to have the protocol go to DRAFT Standard. Guess where that went! In my model at the time there were three groups to consider. 1) Protocol Designers (us). 2) Protocol implementers (vendors, etc.) 3) Protocol End-Users (the folks who bought the stuff). Often members of group (2) overlapped with group (1). The problem that I perceived was that group (3), the "real" users, wanted security (and who really doesn't!) but group (2) didn't want to provide it (for a number of reasons, but high on the list was the fear that it would be hard and expensive to do). So to compensate, we started leaning toward making security mechanisms mandatory (MUST) as applied to implementers. But end-users could always decide not to use them (for such things would be out-of-scope for the IETF). Nice artful dodge that! A good question to ask today (2012) is: "Is this too strict?" Should we be more flexible in how security mechanisms are put into practice? In some ways the problems are trickier today. The Internet is not just for engineers anymore. Group (3) now includes some very non-technical people. We cannot expect these folks to understand and make security trade-offs. We can still offer them security controls, but we have to decide what the defaults are for the average user. Sorry for the length of this message. -Jeff _______________________________________________________________________ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room E17-110A Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu http://jis.qyv.name _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFP6nm68CBzV/QUlSsRAkwnAJ9tNjdGJQBYuoW0Sd5Z+BDCA/vpxQCgiRVY vG1aOcvHocFm+Ij4VDitMew= =fBXh -----END PGP SIGNATURE----- From ynir@checkpoint.com Tue Jun 26 22:35:52 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9021421F85F0 for ; Tue, 26 Jun 2012 22:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 P7DsOZlP51EO for ; Tue, 26 Jun 2012 22:35:52 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF0421F85D1 for ; Tue, 26 Jun 2012 22:35:51 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q5R5ZhnJ019828; Wed, 27 Jun 2012 08:35:43 +0300 X-CheckPoint: {4FEA9AFB-1-1B221DC2-4FFFF} 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.3.213.0; Wed, 27 Jun 2012 08:35:43 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 27 Jun 2012 08:35:43 +0300 From: Yoav Nir To: Nico Williams Date: Wed, 27 Jun 2012 08:34:59 +0300 Thread-Topic: [saag] Should security requirements be MUST? Thread-Index: Ac1UJrE/4hDRRlKsSRe1gNIMQ/fAHQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:35:52 -0000 On Jun 27, 2012, at 2:28 AM, Nico Williams wrote: >> But imagine a client that says to itself, "The cert says these name >> constraints are non-critical =97 presumably for backwards compat. But >> I'll treat them as critical, since I was implemented in late 2012 and >> my implementers knew that name constraints are spiffy." Fewer clients >> will explode upon seeing an unknown-but-critical extension. (Some >> clients will explode anyway, probably, but fewer; and we can much more >> reasonably call those clients buggy.) >=20 > CAs issuing sub-CA certs with non-critical name constraints (NCNC?) > would effectively be issuing MITM sub-CA certs. =20 They would be issuing sub-CAs that can mount a MITM attack only against bro= wsers that do not support name constraints. All it takes is one browser tha= t does support name constraints to get that offending cert discovered. I don't know about Chrome, but there are enough Firefox browsers out there = to believe that if you place a certificate with a name that does not confor= m to the constraints of the CA, you are going to be discovered. This isn't quite as secure as having all browsers break the connection eith= er because the name mismatches or because they don't understand name constr= aints, but it actually is a good example of how mandating the best security= can delay adoption practically forever. Yoav From barryleiba.mailing.lists@gmail.com Wed Jun 27 04:20:03 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EFF21F86C7 for ; Wed, 27 Jun 2012 04:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.95 X-Spam-Level: X-Spam-Status: No, score=-102.95 tagged_above=-999 required=5 tests=[AWL=0.027, 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 p-rYagQ78vK2 for ; Wed, 27 Jun 2012 04:20:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7F1921F86C6 for ; Wed, 27 Jun 2012 04:20:01 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1587799lbb.31 for ; Wed, 27 Jun 2012 04:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=gpmWlFn5vtXgkihxjSDtjLheNIfeA+13Yuse/vaHGKY=; b=eLZycLdOTVUE72WsVdaxhTw2R7X+kHmjR0EfnFCqQM2hA53FcqX418GsTCWIllpK7f d4ewyO8CErnYtSsQLULnoB9vcrYx+9hADlzDDxW1h1L2YZ/ecyRL26Mi+VsSiBo41dIo ZBttvZI5oYaUYrE2zVQvXmDwELf50jy9MjXqJeAZXG/MJUkwtw+ZqUpzJhU46qtYXmUz Y0jpV0SidV7qv9rpWxcHvDts3EgbeFezR+Wsw3jC+Za/id3OFNYFzghTQ3D4WUNySvAH flL4SLKRjqL7CJYkMCAeFnacNaDKyB2RDaNtD67jDJqRZGfONJjoQ16VZ91oRPdBefTd +mgw== MIME-Version: 1.0 Received: by 10.112.26.131 with SMTP id l3mr9478173lbg.80.1340796000837; Wed, 27 Jun 2012 04:20:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Wed, 27 Jun 2012 04:20:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 07:20:00 -0400 X-Google-Sender-Auth: XXOWaoYNOEyVa25qeK8TMNbCBMc Message-ID: From: Barry Leiba To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:20:03 -0000 > Let's get back to Phill's main point which I believe is that > implementers are in a much better position to understand the security > trade-offs involved in a given deployment, then say the protocol > designers. That as protocol designers, we shouldn't presume to > understand all deployment environments and therefore should not > preclude security "settings" (for lack of a better term) that may not > make sense to us, but do make sense in some (unknown to us) context. Maybe the point, then, is that we really need to think separately: that "Security Considerations" are *considerations*, and that if we think there are security issues that MUST be handled in the protocol, those are in the protocol definition itself, not pushed to the end of the document in the Security Considerations section. There's a big difference between specifying how you handle authentication, authorization, integrity, and confidentiality *in the protocol*, and discussing the things that need to be considered when the protocol is implemented and deployed, and is in operation. Barry From paul.hoffman@vpnc.org Wed Jun 27 07:18:18 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384DB21F8786 for ; Wed, 27 Jun 2012 07:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 1Oj0VoF3APf8 for ; Wed, 27 Jun 2012 07:18:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A465821F8778 for ; Wed, 27 Jun 2012 07:18:17 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5REICHN033678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 07:18:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 27 Jun 2012 07:18:11 -0700 Content-Transfer-Encoding: 7bit Message-Id: <093ECD4A-B556-4849-81D0-21D5C1F43C38@vpnc.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.1278) Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:18:18 -0000 On Jun 27, 2012, at 4:20 AM, Barry Leiba wrote: >> Let's get back to Phill's main point which I believe is that >> implementers are in a much better position to understand the security >> trade-offs involved in a given deployment, then say the protocol >> designers. That as protocol designers, we shouldn't presume to >> understand all deployment environments and therefore should not >> preclude security "settings" (for lack of a better term) that may not >> make sense to us, but do make sense in some (unknown to us) context. > > Maybe the point, then, is that we really need to think separately: > that "Security Considerations" are *considerations*, and that if we > think there are security issues that MUST be handled in the protocol, > those are in the protocol definition itself, not pushed to the end of > the document in the Security Considerations section. --Paul Hoffman From touch@isi.edu Wed Jun 27 07:47:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1C721F85E5 for ; Wed, 27 Jun 2012 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.832 X-Spam-Level: X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, 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 lTM9q8mdKqHO for ; Wed, 27 Jun 2012 07:47:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE7E21F841D for ; Wed, 27 Jun 2012 07:47:04 -0700 (PDT) Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5REk4Bk023959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jun 2012 07:46:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <093ECD4A-B556-4849-81D0-21D5C1F43C38@vpnc.org> Date: Wed, 27 Jun 2012 07:46:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17CC1085-2009-46D1-B905-B71DA323E1AD@isi.edu> References: <093ECD4A-B556-4849-81D0-21D5C1F43C38@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Barry Leiba , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:47:05 -0000 On Jun 27, 2012, at 7:18 AM, Paul Hoffman wrote: > On Jun 27, 2012, at 4:20 AM, Barry Leiba wrote: >=20 >>> Let's get back to Phill's main point which I believe is that >>> implementers are in a much better position to understand the = security >>> trade-offs involved in a given deployment, then say the protocol >>> designers. That as protocol designers, we shouldn't presume to >>> understand all deployment environments and therefore should not >>> preclude security "settings" (for lack of a better term) that may = not >>> make sense to us, but do make sense in some (unknown to us) context. >>=20 >> Maybe the point, then, is that we really need to think separately: >> that "Security Considerations" are *considerations*, and that if we >> think there are security issues that MUST be handled in the protocol, >> those are in the protocol definition itself, not pushed to the end of >> the document in the Security Considerations section. >=20 > IMO, the Security Considerations section should discuss concerns about = when SHOULDs and MAYs apply (or do not), and discuss how security has = been addressed (if the doc's main purpose isn't security). It definitely should not contain any new SHOULD/MUST/MAYs - at best, it = might reiterate points for emphasis. Joe= From hallam@gmail.com Wed Jun 27 08:21:23 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D8621F8792 for ; Wed, 27 Jun 2012 08:21:23 -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 5Pz62hKLk+-b for ; Wed, 27 Jun 2012 08:21:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F94D21F8768 for ; Wed, 27 Jun 2012 08:21:22 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1850083obb.31 for ; Wed, 27 Jun 2012 08:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nKolhtnEpHNmV6bustVV4CyAoIb4zy62gOymCo+ruac=; b=jh3YiPemfxA+NweX1kNbzlf60/EWpzSMnIvrLY8uqWDeAUuiZT0ATcNJRHz15snChV xP0qSmBpjT0JHI/TkdIUAMvajDvoY0V1CbmLIv5egTQ2mu2/yBtjezFIFUSssDVTEB36 lDrEvVUkSy4EaxoYJ28EegTZ/jo3XLH6tVc0CJ0f+aKYldmvoJptRqjZx1oyFGWfX8Zp rT8RfawhNZVmFEyVqwvxKX7z5FtWbmm7mqlNCm+WZvE0bbFLaXTkcTMk5iTtP5pcbuRU 5UctSCSzvJOvahbdbsey8JvuQVQTUSKdytalorFYnTwgtCHq1MUNVdqr+sOGB9hGndLN zI8w== MIME-Version: 1.0 Received: by 10.182.197.65 with SMTP id is1mr2386655obc.27.1340810481790; Wed, 27 Jun 2012 08:21:21 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Wed, 27 Jun 2012 08:21:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 11:21:21 -0400 Message-ID: From: Phillip Hallam-Baker To: Chris Palmer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:21:23 -0000 On Tue, Jun 26, 2012 at 6:12 PM, Chris Palmer wrote: > On Mon, Jun 25, 2012 at 2:33 PM, Nico Williams wr= ote: > >> Also, it's not what the RFCs say, it's what browser/OS vendors are >> willing to allow into their trust anchor sets -- they are the >> enforcers, and there is no IETF police. > > We (Google Chrome developers) want name constraints. Critical name > constraints blow up enough clients that it's a deal-breaker. > > But imagine a client that says to itself, "The cert says these name > constraints are non-critical =97 presumably for backwards compat. But > I'll treat them as critical, since I was implemented in late 2012 and > my implementers knew that name constraints are spiffy." Fewer clients > will explode upon seeing an unknown-but-critical extension. (Some > clients will explode anyway, probably, but fewer; and we can much more > reasonably call those clients buggy.) There seems to be some confusion as to the nature of the critical bit here. The critical bit was defined in X.509 (not IETF) and it has one and only one purpose. It tells clients that do not understand the bit or understand the bit but do not observe it to consider the certificate to be invalid. The critical bit has no other semantics. Marking an extension critical does NOT mean 'yes I really mean this'. A client that only processes NCs that have the bit set is just as non-compliant as one that does not implement NCs at all. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Jun 27 08:46:19 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE8521F87A3 for ; Wed, 27 Jun 2012 08:46:19 -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 kyhm3AxmJBlF for ; Wed, 27 Jun 2012 08:46:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC0821F87A2 for ; Wed, 27 Jun 2012 08:46:18 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1881269obb.31 for ; Wed, 27 Jun 2012 08:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dnbrVZLdzTUiJmdU9E5vbb6WWibwj6OjNaZRsPiEx9Y=; b=CmB1drkPzfCP4Zx8tzzBv20Y7p9PTrYhvqo2xW2ppW/83eaHg3cpx0NNZtjh8yGBZj IO79CqI52hnqp9TjrVBUP6ZwdpYoUyEjcjGJ8U2p4GfTWEwiAlqe7APPbdBcod6c2pve JWRb5R4l+nQLXh2XYn0DTUnue2mHv8AUrXBiLrrTX+w7EMNnYyTCHYYH+JezNAG76Vv6 NYo14kV6wYUnIu3prnlqfdSVHg0ZTBD01KcEc4oAmITPwjncz2t20DgiTu0dkH+pIBdt XuorQrV9n+Void9795Sgav/lNA2QTPxSu8AMHwbH8aDIdmxW3p+3Kl8a9mjYfrEx2mQc wUig== MIME-Version: 1.0 Received: by 10.182.77.167 with SMTP id t7mr10906192obw.79.1340811976469; Wed, 27 Jun 2012 08:46:16 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Wed, 27 Jun 2012 08:46:16 -0700 (PDT) In-Reply-To: <4FEA35A8.80201@cs.tcd.ie> References: <4FEA35A8.80201@cs.tcd.ie> Date: Wed, 27 Jun 2012 11:46:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:46:19 -0000 On Tue, Jun 26, 2012 at 6:20 PM, Stephen Farrell wrote: > But - I think that's a discussion for the pkix list. Phill's > question is broader and different and probably more useful to > discuss here. Yes, that was my intention. I think we need to limit specifications to providing security advice and explanations and prohibit security directions. One reason for this is that the security directions are very frequently inappropriate in a real world situation. If you are building an email application then maybe the right response to an expired certificate is to break. If you are building a heart and lung machine or an airplane then your imperative might well be to keep the thing running at all costs unless there are very good, explicit reasons to shut down. Another reason is that I have noticed that arguments over security directions tend to be the most acrimonious and heated. We come from many different application areas and what is a requirement in one area may not be in another. Finally there is the fact that security directions almost never have a bearing on interoperability. They are not necessary decisions for a standards organization to take. So why spend hours of time debating an issue that we don't need to discuss, that causes a lot of unpleasantness and is going to be ignored anyway? If people take a close look at PKIX they will see that all the spec talks about is what steps MUST be taken to decide if a certificate is valid. PKIX does not tell clients how to evaluate the trustworthiness of a certificate or whether to accept or reject it (at least not as far as I can remember). So an Internet application is fully entitled to accept a certificate that is invalid according to PKIX or reject one that is valid. And there are many situations where this makes sense. I would prefer my mail server to connect to another server via SSL and an expired certificate is to connect en-clair with no encryption. Rather than telling people what to do, specifications should state what the consequences of different implementation choices. The only places I would want to see security directions is in a profile document whose sole purpose is to specify a set of security directions for a specific audience. So for example, a company outsourcing their email would likely want to have some assurance that it was being processed in accordance with a specific set of security and policy requirements. It would be very useful if there was a document that said something like 'mail server SHALL support STARTTLS, SHALL offer ciphersuites mumble, SHALL publish its inbound and outbound security policy via DKIM, DANE, TBS and so on. These are important and useful discussions when they are centered on a very specific application domain and completely useless when focused on a single protocol that is in development. We have a like issue when people argue over mandatory cipher suites for platform specifications like XML Signature, JSON signature etc. Its the type of argument that everyone can join in because everyone can have an opinion. But the choice of cipher suite is really something that should be part of a separate discussion. -- Website: http://hallambaker.com/ From marsh@extendedsubset.com Wed Jun 27 09:31:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB60121F8796 for ; Wed, 27 Jun 2012 09:31:34 -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 ueDc5MESUXHn for ; Wed, 27 Jun 2012 09:31:34 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 39BEE21F874A for ; Wed, 27 Jun 2012 09:31:34 -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 1Sjv9R-0001ct-RE; Wed, 27 Jun 2012 16:31:33 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E769760C2; Wed, 27 Jun 2012 16:31:32 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+tlhievB+CKPaxgrFywAiEBScU/bk1ZRI= Message-ID: <4FEB3564.2000306@extendedsubset.com> Date: Wed, 27 Jun 2012 11:31:32 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 16:31:34 -0000 On 06/27/2012 06:20 AM, Barry Leiba wrote: > > Maybe the point, then, is that we really need to think separately: > that "Security Considerations" are *considerations*, and that if we > think there are security issues that MUST be handled in the protocol, > those are in the protocol definition itself, not pushed to the end of > the document in the Security Considerations section. Would you be against giving them a mention or a reference in the Security Considerations section too? I really find it valuable to be able to refer to that section for a reasonably thorough review of all the security-affecting aspects of the design, implementation, and deployment. IOW, I don't think of it as being "pushed to the end of the document" I think of it as "this stuff is important enough to deserve its own section and not just scattered throughout the document". - Marsh From hallam@gmail.com Wed Jun 27 10:26:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44F121F86CB for ; Wed, 27 Jun 2012 10:26:34 -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 YP6jCQ8g2WHv for ; Wed, 27 Jun 2012 10:26:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C318A21F86B8 for ; Wed, 27 Jun 2012 10:26:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2000397obb.31 for ; Wed, 27 Jun 2012 10:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9ACU3P48fRTi1oQt5HKXiPEviCG5sX0Njdo0QCfBy6g=; b=b6jeYd3RiIh6TNwY7GJpQqEJJ7qpdRPbPNj1/7VAb3tNwe/gNUc4OIm2vfG4/mtvnb xHPRFguQctxJbHxxjrXxa4QQXKoZthpWmnoBdjbKSoRgwCpZJAWSuRl8YB7Qt4RDj4aR hPZp/SFCRuuJNYBvnPmaBU1clOTAKXRPScesleAeN4+5QoCMKHlFbbXtnKMKFPzWYwd8 qeKZg1qe1HPypEXa380Oz4O86mLrfK/JfRB+yS8jg8gjk//zFPOK6RolmJ4YT7kgHtNR LkXSBvRwg6lf/ua6Gp1+WAR4jo+v+6V1tGxP3ugsMW60pfmk6JqcgWgeTPrRON5T1n5n iA+g== MIME-Version: 1.0 Received: by 10.182.12.74 with SMTP id w10mr21293346obb.54.1340817993319; Wed, 27 Jun 2012 10:26:33 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Wed, 27 Jun 2012 10:26:33 -0700 (PDT) Date: Wed, 27 Jun 2012 13:26:33 -0400 Message-ID: From: Phillip Hallam-Baker To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] MAC first then encrypt or encrypt then MAC. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:26:34 -0000 OK, so I think I know the answer to this one, but every single time I submit a spec doing it one way, someone will always tell me that the other is the way to go. And very rarely will anyone give a reason other than 'that is how to do it'. And no, 'just use TLS or DTLS' is not an option in this particular protocol. I have found http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html but while the paper is very good and worth reading, it is focused on public key issues. I am wondering if some of the 'you must sign first' advice is coming from people translating advice specific to public key back to symmetric key protocols. What I am planning to do is: 1) Starting from a master shared secret km produce distinct keys ks, ke for signing and encryption respectively. [e.g. ks = MAC ("sign", km), ke = MAC ("encrypt", km)] 2) Construct either Encrypt-then-sign Message = Encrypt (Payload, ke) + Authenticate (Encrypt (Payload, ke), ks) Sign-the-encrypt Message = Encrypt (Payload + Authenticate (Payload, ks), ke) [I am aware that certain communities would advise P2 = Encrypt (Payload + Authenticate (Payload, ks), ke) Message = Encrypt (P2+ Authenticate (P2, ks), ke) But I don't have the room for it] What I am really looking for here is not so much an argument as a reference I can cite. Looking at the current JSON signature etc spec it looks to me like Encrypt-then-sign is expected. This is to be used in: http://www.ietf.org/id/draft-hallambaker-omnibroker-00.txt in case you need context. -- Website: http://hallambaker.com/ From tlyu@mit.edu Wed Jun 27 11:28:49 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30EA11E8099 for ; Wed, 27 Jun 2012 11:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.066 X-Spam-Level: X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_OEM=0.533, 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 Owawi1Rxwrci for ; Wed, 27 Jun 2012 11:28:49 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id BBFD821F8607 for ; Wed, 27 Jun 2012 11:28:42 -0700 (PDT) X-AuditID: 12074424-b7f2a6d0000008bf-51-4feb50d9197b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 3F.4D.02239.9D05BEF4; Wed, 27 Jun 2012 14:28:42 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q5RISfu8004457; Wed, 27 Jun 2012 14:28:41 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q5RISe0T019539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jun 2012 14:28:41 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id q5RISeVk014453; Wed, 27 Jun 2012 14:28:40 -0400 (EDT) To: Phillip Hallam-Baker References: From: Tom Yu Date: Wed, 27 Jun 2012 14:28:40 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 27 Jun 2012 13:26:33 -0400") Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrnsr4LW/wdUDTBZXlx9nspjS38nk wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGW8u7eJreAAR8Xlmb1MDYxv2boYOTkkBEwk Dq7pYYKwxSQu3FsPFOfiEBLYxyjx42AHO4SzgVHi65G/zBDOFSaJv02fWUBahAS6GCV231cD sUUEtCWO7tvCCmIzCwhK9M56BzZWWMBe4vv1LUwQ9QEScy90AdkcHGwC0hJHF5eBmCwCqhIH psWAjOcUmM4o0fCuE6ycV8BC4tf7FWCreAQ4JSZ/62GGiAtKnJz5hAVilZbEjX8vmSYwCs5C kpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGcKC6qOxgbD6kdIhR gINRiYdX2eu1vxBrYllxZe4hRkkOJiVR3l0+QCG+pPyUyozE4oz4otKc1OJDjBIczEoivDf0 gHK8KYmVValF+TApaQ4WJXHe6yk3/YUE0hNLUrNTUwtSi2CyMhwcShK8rMCIFBIsSk1PrUjL zClBSDNxcIIM5wEa/scfZHhxQWJucWY6RP4Uo6KUOO9NkIQASCKjNA+uF5ZIXjGKA70izPsb pIoHmITgul8BDWYCGsyx6QXI4JJEhJRUA+NMe9Utu1Lat96e1XXRU3OCnqpo7rOVUzVWfDIq tWd7bfbksHt+um13g2BSr7x+cqXazZ0feY+38l45mfpa4VTzwknxl/+80V9/oeCkv+De104L zOqkT14ILzqu3FjgG5+nuIklqoXRPLa3+NObPxUyfY/sWyfsO2Wf0yTndWjZ9bKN7puZIpVY ijMSDbWYi4oTAUitXnv/AgAA Cc: saag@ietf.org Subject: Re: [saag] MAC first then encrypt or encrypt then MAC. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:28:50 -0000 Phillip Hallam-Baker writes: > OK, so I think I know the answer to this one, but every single time I > submit a spec doing it one way, someone will always tell me that the > other is the way to go. And very rarely will anyone give a reason > other than 'that is how to do it'. > > And no, 'just use TLS or DTLS' is not an option in this particular protocol. > > I have found http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > but while the paper is very good and worth reading, it is focused on > public key issues. I am wondering if some of the 'you must sign first' > advice is coming from people translating advice specific to public key > back to symmetric key protocols. Are you focusing on symmetric key use cases? I think http://cseweb.ucsd.edu/~mihir/papers/oem.pdf and related work might be what you want to look at. What security properties are you looking for? In the above paper, only Encrypt-then-MAC using a strongly unforgeable MAC provides IND-CTXT integrity and NM-CPA security; the other alternatives are weaker. From melinda.shore@gmail.com Wed Jun 27 12:03:46 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA0E11E80BE for ; Wed, 27 Jun 2012 12:03:46 -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 AXOag-qnNeVe for ; Wed, 27 Jun 2012 12:03:46 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74D1711E80BD for ; Wed, 27 Jun 2012 12:03:46 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2027062pbc.31 for ; Wed, 27 Jun 2012 12:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ry/4y1Q0LzNA4CcVKBDceNXemGgcJ5QJjB6SpEnWgwA=; b=vA08KJzGMvhsWSV5DmL4K8K3GyzS6fehNWPRYuqyt1Tgl6CLdqF5UsDcX3cw1kR50M VYS6OTj33dXMgz4K7xKnsr8ZgO7qq5fCdavQnqQyBmNkm2U6PwF1Q5Xci/CZ8zoDzL8l SVdMq50mKLJ/kYR0nSTfzoygWP0/ZDUKhFhejzUklB8bbNMn6Ry4MsQ/oY22piL+rBH7 jcVjcwWj/cvTir/X6LDijLVkBJd5vxkekv+VHtkBzcTIr0SjgUlPOe3lK6u2R27xYJFW fqBVhx8cdfjBeOF1DRychTPD37aXGMeUeHD63NWH7fSm+Ke0QGYyhCTG9fo7HCLjmSuy 1MRQ== Received: by 10.68.241.232 with SMTP id wl8mr66149427pbc.106.1340823826289; Wed, 27 Jun 2012 12:03:46 -0700 (PDT) Received: from spandex.local (66-230-81-117-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.117]) by mx.google.com with ESMTPS id nh8sm15937902pbc.60.2012.06.27.12.03.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 12:03:45 -0700 (PDT) Message-ID: <4FEB590F.8020800@gmail.com> Date: Wed, 27 Jun 2012 11:03:43 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: saag@ietf.org References: <093ECD4A-B556-4849-81D0-21D5C1F43C38@vpnc.org> In-Reply-To: <093ECD4A-B556-4849-81D0-21D5C1F43C38@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:03:47 -0000 On 6/27/12 6:18 AM, Paul Hoffman wrote: > On Jun 27, 2012, at 4:20 AM, Barry Leiba wrote: >> Maybe the point, then, is that we really need to think separately: >> that "Security Considerations" are *considerations*, and that if we >> think there are security issues that MUST be handled in the protocol, >> those are in the protocol definition itself, not pushed to the end of >> the document in the Security Considerations section. > Here, too. That's one of those things that seems obvious when someone says it, but I don't think I've seen someone say this before. So yes, definitely. Melinda From marsh@extendedsubset.com Wed Jun 27 12:47:55 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7336521F85D1 for ; Wed, 27 Jun 2012 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 rHmXbw33AFMQ for ; Wed, 27 Jun 2012 12:47:54 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id A45DE21F85D0 for ; Wed, 27 Jun 2012 12:47:54 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SjyDS-000Bh8-8g; Wed, 27 Jun 2012 19:47:54 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3185160C2; Wed, 27 Jun 2012 19:47:53 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19zfX5mBocT3DzxDPR2zJUv/93d8JZz6Bw= Message-ID: <4FEB6367.3060509@extendedsubset.com> Date: Wed, 27 Jun 2012 14:47:51 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] MAC first then encrypt or encrypt then MAC. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:47:55 -0000 On 06/27/2012 12:26 PM, Phillip Hallam-Baker wrote: > OK, so I think I know the answer to this one, but every single time I > submit a spec doing it one way, someone will always tell me that the > other is the way to go. And very rarely will anyone give a reason > other than 'that is how to do it'. Well how about sidestepping the debate and using an intrinsically authenticated encryption mode such as GCM, CCM, or EAX? http://en.wikipedia.org/wiki/GCM_mode http://en.wikipedia.org/wiki/CCM_mode http://en.wikipedia.org/wiki/EAX_mode Why: * The encryption and message authentication are integrated rather than separate operations. * There's less to go wrong. * Often more efficient. * GCM parallelizes. * GCM is standardized by NIST and is NSA Suite B. * GCM is referenced by RFC 4106 (GCM for IPsec ESP) and 5288 (AES GCM for TLS) * Packaged and tested implementations are available in many crypto libraries. * The modes I listed are believed patent-free. Why not: * GCM really needs a 128 bit or longer tag. But you were probably looking at a minimum of 160 bits for SHA-1 anyway. * It's hard to choose among the options. - Marsh From hallam@gmail.com Wed Jun 27 13:02:28 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8A21F85D7 for ; Wed, 27 Jun 2012 13:02:28 -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 eyuKSFfSo8VI for ; Wed, 27 Jun 2012 13:02:28 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0643621F85D5 for ; Wed, 27 Jun 2012 13:02:27 -0700 (PDT) Received: by yhfq11 with SMTP id q11so1618022yhf.15 for ; Wed, 27 Jun 2012 13:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AboXO8JA001CFSIgROVKgAvrfAtw4WdOWRzdpb50saI=; b=tchFdmwt9kxzqzM8pttaGFvrnG+AeLW5E5os7mWl55F8NBJs3C7X3J/hWwvUyqu/g1 qsUaXmmf1t1ApXdd8QqNgFHuvQqM2hOZH6eiF1Shui+ocdTCWTpbvHvacgFXzMWddy/i cR8BNMJkiF/CqIPojqGyEHgJUyO321eR97qtHzaX/ubG66f+3mbFGLLA5KLLzK66FXr/ i6HAEhojKBabMMwfqfqgB5/rf+CJGDvzmWzWs44f65grWnz7XpPOA8tagrAzFQAyPmz2 WVMzVV2WRGyGIMIDEdRSnBSIixtjx735LJQu7/67V6xUf7tGyO60Oxy+GCP8tS20ulFu Fltg== MIME-Version: 1.0 Received: by 10.60.18.114 with SMTP id v18mr21998735oed.34.1340827347241; Wed, 27 Jun 2012 13:02:27 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Wed, 27 Jun 2012 13:02:27 -0700 (PDT) In-Reply-To: <4FEB6367.3060509@extendedsubset.com> References: <4FEB6367.3060509@extendedsubset.com> Date: Wed, 27 Jun 2012 16:02:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] MAC first then encrypt or encrypt then MAC. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:02:28 -0000 On Wed, Jun 27, 2012 at 3:47 PM, Marsh Ray wrote: > On 06/27/2012 12:26 PM, Phillip Hallam-Baker wrote: >> >> OK, so I think I know the answer to this one, but every single time I >> submit a spec doing it one way, someone will always tell me that the >> other is the way to go. And very rarely will anyone give a reason >> other than 'that is how to do it'. > > > Well how about sidestepping the debate and using an intrinsically > authenticated encryption mode such as GCM, CCM, or EAX? > > http://en.wikipedia.org/wiki/GCM_mode > http://en.wikipedia.org/wiki/CCM_mode > http://en.wikipedia.org/wiki/EAX_mode > > Why: > > * The encryption and message authentication are integrated rather than > separate operations. > > * There's less to go wrong. > > * Often more efficient. > > * GCM parallelizes. > > * GCM is standardized by NIST and is NSA Suite B. > > * GCM is referenced by RFC 4106 (GCM for IPsec ESP) and 5288 (AES GCM for > TLS) > > * Packaged and tested implementations are available in many crypto > libraries. > > * The modes I listed are believed patent-free. > > Why not: > > * GCM really needs a 128 bit or longer tag. But you were probably looking at > a minimum of 160 bits for SHA-1 anyway. > > * It's hard to choose among the options. > > - Marsh I think you are right. But I am not comfortable with doing more than making support for something like GCM a requirement for the service side at this point. Selling the protocol is going to be hard enough without doing trailblazing. I can make a very good case for requiring combi mode on the server so that embedded devices can be supported. Requiring it on the client side would be problematic given the need to implement in various scripting languages, -- Website: http://hallambaker.com/ From elear@cisco.com Wed Jun 27 00:59:59 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4252F21F8650 for ; Wed, 27 Jun 2012 00:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfMuhPdDtkSm for ; Wed, 27 Jun 2012 00:59:58 -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 09F0B21F8648 for ; Wed, 27 Jun 2012 00:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=elear@cisco.com; l=5171; q=dns/txt; s=iport; t=1340783998; x=1341993598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2O+g0ndd0rCgku2JkFD+blUC/G8ZqyNBK35h8ZcI6fQ=; b=jqKGCDnm60PRBaAtd2JwXSAKVZQSQY+xJPjiosEwSv7gvif2ZVowuwD3 rPjcAqsSCeM2AARc6EU2AlneRh5/TZmcJuVX5cjeGd4eAaWdJv+Mb+eF1 75/J+P9fyfKcKdY5HChaVd5WElaplhBuGNoDp+JbZZm3rfeHiYVTS29YF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADq86k+tJV2a/2dsb2JhbABCAw62FoEHghkBAQQBAQEPASc0CxACAQgOKBAnCyUCBA4FIodpC5kdoCaLN4JpgkFgA4smigyBEoUwh1uBZoImOQ X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="96403300" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jun 2012 07:59:57 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5R7xvOE003660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Jun 2012 07:59:57 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.20]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 02:59:57 -0500 From: "Eliot Lear (elear)" To: Jeffrey Schiller Thread-Topic: [saag] Should security requirements be MUST? Thread-Index: AQHNU+jKXo37eZxo802X6wieTwRkk5cNkriAgAA+kYD///yUYg== Date: Wed, 27 Jun 2012 07:59:56 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19000.003 x-tm-as-result: No--55.859900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Jun 2012 08:03:41 -0700 Cc: "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:59:59 -0000 Jeff, Great and timely discussion! I've just returned from this year's WEIS[1] that had a keen focus on your l= ast point: it is very hard for users to make the right decision, and indeed= the research challenged the whole permission-based approach in mobile devi= ces in part due to UI design issues and in part because security wasn't top= of mind. What does this tell us? It's early days but perhaps it confirms that users = are willing to make trade-offs and that should be respected... up to a poin= t where externalities could be introduced, and that's when this discussion = gets really fun! As Nico hinted there's a body of epidemiological work that needs to be cons= idered and is not always intuitive. Combine this with the fact that protoco= ls and don't always get uses in ways that were envisioned by their designer= s and now we're REALLY off to the races! Eliot [1] http://weis2012.econinfosec.org/ On Jun 27, 2012, at 5:12 AM, "Jeffrey Schiller" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Let's get back to Phill's main point which I believe is that > implementers are in a much better position to understand the security > trade-offs involved in a given deployment, then say the protocol > designers. That as protocol designers, we shouldn't presume to > understand all deployment environments and therefore should not > preclude security "settings" (for lack of a better term) that may not > make sense to us, but do make sense in some (unknown to us) context. >=20 > Let me expand a bit on this and give some history (as a Security AD > from 1994-2003, I have some history in my head!). >=20 > A lot of the security area's "strictness" evolved in the mid 1990's > when many (outside of the Security Area) folks in the IETF really > didn't care much about security. Internet Security threats were mostly > kids, not the organized crime and state actors that we see today. We > used to have (still do?) a requirement that all RFCs have a "Security > Considerations" section. The purpose of this requirement was to get > folks to think through security issues. It was only partially > successful. More people asked me "What weasel words should I put in > the Security Considerations Section to get it approved" then asked me > "How can we truly address security concerns in this protocol." >=20 > My favorite situation involved the elevation of a protocol to DRAFT > Standard. In order to become a DRAFT Standard, a protocol needed to > have at least two independent implementations of all features of the > protocol. Features that did not have independent implementations > needed to be removed from the standard prior to elevation to DRAFT. So > I was approached about removing all security from a protocol because > well... there weren't two implementations of the security features and > the document authors wanted to have the protocol go to DRAFT > Standard. Guess where that went! >=20 > In my model at the time there were three groups to consider. >=20 > 1) Protocol Designers (us). > 2) Protocol implementers (vendors, etc.) > 3) Protocol End-Users (the folks who bought the stuff). >=20 > Often members of group (2) overlapped with group (1). The problem that > I perceived was that group (3), the "real" users, wanted security (and > who really doesn't!) but group (2) didn't want to provide it (for a > number of reasons, but high on the list was the fear that it would be > hard and expensive to do). >=20 > So to compensate, we started leaning toward making security mechanisms > mandatory (MUST) as applied to implementers. But end-users could > always decide not to use them (for such things would be out-of-scope > for the IETF). Nice artful dodge that! >=20 > A good question to ask today (2012) is: "Is this too strict?" Should > we be more flexible in how security mechanisms are put into practice? >=20 > In some ways the problems are trickier today. The Internet is not just > for engineers anymore. Group (3) now includes some very non-technical > people. We cannot expect these folks to understand and make security > trade-offs. We can still offer them security controls, but we have to > decide what the defaults are for the average user. >=20 > Sorry for the length of this message. >=20 > -Jeff >=20 > _______________________________________________________________________ > Jeffrey I. Schiller > Information Services and Technology > Massachusetts Institute of Technology > 77 Massachusetts Avenue Room E17-110A > Cambridge, MA 02139-4307 > 617.253.0161 - Voice > jis@mit.edu > http://jis.qyv.name > _______________________________________________________________________ >=20 >=20 >=20 >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iD8DBQFP6nm68CBzV/QUlSsRAkwnAJ9tNjdGJQBYuoW0Sd5Z+BDCA/vpxQCgiRVY > vG1aOcvHocFm+Ij4VDitMew=3D > =3DfBXh > -----END PGP SIGNATURE----- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From kent@bbn.com Thu Jun 28 10:43:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974FB21F8549 for ; Thu, 28 Jun 2012 10:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL5sKC2+M1IV for ; Thu, 28 Jun 2012 10:43:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5C21F85C6 for ; Thu, 28 Jun 2012 10:43:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59292 helo=[192.168.1.2]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkIki-000BQh-DR; Thu, 28 Jun 2012 13:43:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 28 Jun 2012 12:52:07 -0400 To: Chris Palmer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 17:43:40 -0000 At 3:12 PM -0700 6/26/12, Chris Palmer wrote: >... >We (Google Chrome developers) want name constraints. Critical name >constraints blow up enough clients that it's a deal-breaker. > >But imagine a client that says to itself, "The cert says these name >constraints are non-critical - presumably for backwards compat. But >I'll treat them as critical, since I was implemented in late 2012 and >my implementers knew that name constraints are spiffy." I don't understand what you're trying to say above. An RP that understands an extension is expected (i.e., MUST) process it, irrespective of whether the extension is marked critical. So the phrase of "I'll treat them as critical ..." makes no sense to me. The critical flag is used by a CA to force an RP to reject a cert if the extension is marked critical AND the RP does not know how to process the extension, period. It's a way for a CA to say "if you can't process (enforce) the data in this extension, I don't want you to rely on this cert, because I (the CA) believe that the extension is very important to safe use of the public key in the cert. Steve From kent@bbn.com Thu Jun 28 10:43:42 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372CB21F85D8 for ; Thu, 28 Jun 2012 10:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 5f2ill+KwBDi for ; Thu, 28 Jun 2012 10:43:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 33AD821F85C6 for ; Thu, 28 Jun 2012 10:43:37 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59292 helo=[192.168.1.2]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkIki-000BQh-W3; Thu, 28 Jun 2012 13:43:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4FEB3564.2000306@extendedsubset.com> References: <4FEB3564.2000306@extendedsubset.com> Date: Thu, 28 Jun 2012 13:36:33 -0400 To: Marsh Ray From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-871217080==_ma============" Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 17:43:42 -0000 --============_-871217080==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:31 AM -0500 6/27/12, Marsh Ray wrote: >On 06/27/2012 06:20 AM, Barry Leiba wrote: >> >>Maybe the point, then, is that we really need to think separately: >>that "Security Considerations" are *considerations*, and that if we >>think there are security issues that MUST be handled in the protocol, >>those are in the protocol definition itself, not pushed to the end of >>the document in the Security Considerations section. > >Would you be against giving them a mention or a reference in the >Security Considerations section too? > >I really find it valuable to be able to refer to that section for a >reasonably thorough review of all the security-affecting aspects of >the design, implementation, and deployment. > >IOW, I don't think of it as being "pushed to the end of the >document" I think of it as "this stuff is important enough to >deserve its own section and not just scattered throughout the >document". > >- Marsh If the RFC is a security spec, the info will be scattered throughout the doc, and it would be onerous to repeat that info in the SCC. In such RFCs it makes sense to discuss deployment/use considerations in the SCC, apropos the section's name. (After all, very few RFcs mandate use of secruity mechanisms; they mandate that implementations incorporate support of the mechanisms to enable their use when users and sys admins so choose.) In RFCs that are not security-specific, the SCC does tend to be the place where the secruity mechanisms described in the RFC are summarized and there is (should be) discussion of how and when to employ the mechanisms offered as part of the protocol. I admit that many RFCs that are not security-centric don't do a great job of this. Steve --============_-871217080==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] Should security requirements be MUST?
At 11:31 AM -0500 6/27/12, Marsh Ray wrote:
On 06/27/2012 06:20 AM, Barry Leiba wrote:

Maybe the point, then, is that we really need to think separately:
that "Security Considerations" are *considerations*, and that if we
think there are security issues that MUST be handled in the protocol,
those are in the protocol definition itself, not pushed to the end of
the document in the Security Considerations section.

Would you be against giving them a mention or a reference in the Security Considerations section too?

I really find it valuable to be able to refer to that section for a reasonably thorough review of all the security-affecting aspects of the design, implementation, and deployment.

IOW, I don't think of it as being "pushed to the end of the document" I think of it as "this stuff is important enough to deserve its own section and not just scattered throughout the document".
- Marsh

If the RFC is a security spec, the info will be scattered throughout the doc, and it would be onerous to repeat that info in the SCC. In such RFCs it makes sense to discuss deployment/use considerations in the SCC, apropos the section's name.  (After all, very few RFcs mandate use of secruity mechanisms; they mandate that implementations incorporate support of the mechanisms to enable their use when users and sys admins so choose.)

In RFCs that are not security-specific, the SCC does tend to be the place where
the secruity mechanisms described in the RFC are summarized and there is (should be) discussion of how and when to employ the mechanisms offered as part of the protocol. I admit that many RFCs that are not security-centric don't do a great job of this.

Steve


--============_-871217080==_ma============-- From hotz@jpl.nasa.gov Thu Jun 28 11:23:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E5F21F85D5 for ; Thu, 28 Jun 2012 11:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 kRHUtBa3VGmP for ; Thu, 28 Jun 2012 11:23:38 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 738B621F8598 for ; Thu, 28 Jun 2012 11:23:37 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5SINURT029706 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 28 Jun 2012 11:23:31 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Thu, 28 Jun 2012 11:23:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93A07AA7-71EE-44B0-AA39-3E9617D317EE@jpl.nasa.gov> References: <4FEA35A8.80201@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 18:23:40 -0000 On Jun 27, 2012, at 8:46 AM, Phillip Hallam-Baker wrote: > On Tue, Jun 26, 2012 at 6:20 PM, Stephen Farrell > wrote: >=20 >> But - I think that's a discussion for the pkix list. Phill's >> question is broader and different and probably more useful to >> discuss here. >=20 > Yes, that was my intention. >=20 > I think we need to limit specifications to providing security advice > and explanations and prohibit security directions. Disagree. If the purpose of a protocol is to provide some level of security, then = the specification MUST specify what must be done in order to provide = that security. I generally agree with Barry's comment about Security = Considerations being "considerations" and not requirements. I also happen to believe that if a protocol needs some security features = in order for its results to be believed those MUST be specified = somewhere. If those features purely relate to deployment, they could be = relegated to discussion in the Security Considerations section. = However, if specific deployment constraint must be satisfied to provide = some important security property, then I'm OK with putting a MUST in the = Security Considerations section for that. > One reason for this is that the security directions are very > frequently inappropriate in a real world situation. If you are > building an email application then maybe the right response to an > expired certificate is to break. If you are building a heart and lung > machine or an airplane then your imperative might well be to keep the > thing running at all costs unless there are very good, explicit > reasons to shut down. >=20 > Another reason is that I have noticed that arguments over security > directions tend to be the most acrimonious and heated. We come from > many different application areas and what is a requirement in one area > may not be in another. >=20 > Finally there is the fact that security directions almost never have a > bearing on interoperability. They are not necessary decisions for a > standards organization to take. So why spend hours of time debating an > issue that we don't need to discuss, that causes a lot of > unpleasantness and is going to be ignored anyway? Because the issues need to be understood in order to discover the best = compromises among the possibilities. I also deplore how acrimonious the = discussions get because that prevents us from doing that discovery = properly. I suppose if someone thinks his/her job may depend on the = decision going a particular way, I can sympathize, but it still gets in = the way. > If people take a close look at PKIX they will see that all the spec > talks about is what steps MUST be taken to decide if a certificate is > valid. PKIX does not tell clients how to evaluate the trustworthiness > of a certificate or whether to accept or reject it (at least not as > far as I can remember). I generally agree with the concept of RFCs providing mechanisms which = can be tailored to specific needs. Taking that to a dysfunctional = extreme you can wind up with standards that try to serve such a diverse = set of customers that they wind up being too complex to implement (with = realistically available resources anyway) and do not provide = sufficiently visible (or understandable) tailoring advice. > So an Internet application is fully entitled to accept a certificate > that is invalid according to PKIX or reject one that is valid. And > there are many situations where this makes sense. I would prefer my > mail server to connect to another server via SSL and an expired > certificate is to connect en-clair with no encryption. I would argue that if that situation occurs in a non-trivial number of = cases then the standards in question have problems which need to be = fixed in order to better serve their intended purpose. Being easy to = deploy properly is a necessary design goal. > Rather than telling people what to do, specifications should state > what the consequences of different implementation choices. Agree, but I'm not sure that changes anything. > The only places I would want to see security directions is in a > profile document whose sole purpose is to specify a set of security > directions for a specific audience. Too narrow. I think it's more complex than that. For a simple spec, I think you should describe security properties = w.r.t. deployment (or other) choices. If it becomes difficult to relate = the audience to all the properties, then a separate spec may be needed, = especially if the choices are significantly disparate. > So for example, a company outsourcing their email would likely want to > have some assurance that it was being processed in accordance with a > specific set of security and policy requirements. It would be very > useful if there was a document that said something like 'mail server > SHALL support STARTTLS, SHALL offer ciphersuites mumble, SHALL publish > its inbound and outbound security policy via DKIM, DANE, TBS and so > on. It's way too easy to overload the typical customer which choices they = don't understand or (maybe legitimately) don't care about. > These are important and useful discussions when they are centered on a > very specific application domain and completely useless when focused > on a single protocol that is in development. ??? ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From jhutz@cmu.edu Thu Jun 28 11:37:09 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7D121F854F for ; Thu, 28 Jun 2012 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqjItpTld-pk for ; Thu, 28 Jun 2012 11:37:09 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id E765821F8503 for ; Thu, 28 Jun 2012 11:37:08 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q5SIb1Gk007662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 14:37:01 -0400 (EDT) From: Jeffrey Hutzelman To: Stephen Kent In-Reply-To: <9846_1340905422_q5SHhfoJ012996_p06240805cc123b2eeb7e@[192.168.1.2]> References: <9846_1340905422_q5SHhfoJ012996_p06240805cc123b2eeb7e@[192.168.1.2]> Content-Type: text/plain; charset="UTF-8" Date: Thu, 28 Jun 2012 14:36:13 -0400 Message-ID: <1340908573.31047.337.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: Phillip Hallam-Baker , saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 18:37:09 -0000 On Thu, 2012-06-28 at 12:52 -0400, Stephen Kent wrote: > The critical flag is used by a CA to force an RP to reject a cert if > the extension is marked critical AND the RP does not know how to process > the extension, period. It's a way for a CA to say "if you can't process > (enforce) the data in this extension, I don't want you to rely on this cert, > because I (the CA) believe that the extension is very important to safe > use of the public key in the cert. Or phrased another way, because the extension contains information restricting the use of the certificate or the public key contained therein. From marsh@extendedsubset.com Thu Jun 28 13:18:45 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3541711E809F for ; Thu, 28 Jun 2012 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v49ih6PyhM-E for ; Thu, 28 Jun 2012 13:18:43 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9514111E8087 for ; Thu, 28 Jun 2012 13:18:43 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SkLAo-000BO8-Fq; Thu, 28 Jun 2012 20:18:42 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5DA9963C0; Thu, 28 Jun 2012 20:18:40 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/OyG3Ylpio/r3FXG8NeyGwEJKSWx5l9AU= Message-ID: <4FECBC1C.9060304@extendedsubset.com> Date: Thu, 28 Jun 2012 15:18:36 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4FEA35A8.80201@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:18:45 -0000 On 06/27/2012 10:46 AM, Phillip Hallam-Baker wrote: > > I think we need to limit specifications to providing security advice > and explanations and prohibit security directions. > > One reason for this is that the security directions are very > frequently inappropriate in a real world situation. We're talking about IETF internet-oriented protocols. The end-to-end principle implies that security has to reside in the protocols implemented at the endpoints because it cannot reside in the network itself. > If you are > building an email application then maybe the right response to an > expired certificate is to break. If you are building a heart and lung > machine or an airplane then your imperative might well be to keep the > thing running at all costs unless there are very good, explicit > reasons to shut down. One of these scenarios is far more relevant to the IETF scope than the other. > Another reason is that I have noticed that arguments over security > directions tend to be the most acrimonious and heated. Perhaps this a symptom that security is important. > We come from > many different application areas and what is a requirement in one area > may not be in another. Document it! Seriously, working out the when, where, and why of security requirements sounds like a very valuable activity. > Finally there is the fact that security directions almost never have a > bearing on interoperability. Look at it another way: it's rarely possible for a protocol to provide both perfect security and perfect interoperability simultaneously. Consequently the entire purpose of many protocol security controls is to detect the possibility of an insecure connection and then refuse to interoperate. > They are not necessary decisions for a > standards organization to take. So why spend hours of time debating an > issue that we don't need to discuss, that causes a lot of > unpleasantness and is going to be ignored anyway? > > If people take a close look at PKIX they will see that all the spec > talks about is what steps MUST be taken to decide if a certificate is > valid. PKIX does not tell clients how to evaluate the trustworthiness > of a certificate or whether to accept or reject it (at least not as > far as I can remember). > > So an Internet application is fully entitled to accept a certificate > that is invalid according to PKIX or reject one that is valid. And > there are many situations where this makes sense. I would prefer my > mail server to connect to another server via SSL and an expired > certificate is to connect en-clair with no encryption. > > Rather than telling people what to do, specifications should state > what the consequences of different implementation choices. I agree with this, except in the cases where one endpoint relies on another to perform certain checks. For example, an https server relies upon a web browser to validate the cert seen by the client. Short of requiring TLS client certs, the server has no ability to prove the absence of an active MitM attacker. So unless we take the position that an https server has no interest in the security of the connection, we need to say that a correct implementation of https requires the client to do as good a job validating the cert as the legitimate server would have done had it been able to. > We have a like issue when people argue over mandatory cipher suites > for platform specifications like XML Signature, JSON signature etc. > Its the type of argument that everyone can join in because everyone > can have an opinion. But the choice of cipher suite is really > something that should be part of a separate discussion. There's a difference here between signature algorithms and encryption cipher suites. A signature algorithm is relied upon to ensure the integrity of the negotiated information (such as the choice of cipher). What this means in practice is that when the signature algorithm is optional or negotiable usually the attacker ends up being free to choose among all supported options the weakest configuration to attack. An example is what happened with XML encryption. The signature is optional, so rather than need to forge any type of signature the attacker is free to simply omit the signature altogether. This enabled a very practical attack on the encryption which, under the right circumstances, is severe enough to defeat the encryption entirely. > http://blog.cryptographyengineering.com/2011/10/attack-of-week-xml-encryption.html So it's essential that standards which rely on a signature algorithm for security specify a set of minimum acceptable algorithms from the very first version that will be expected to interoperate. - Marsh From touch@isi.edu Thu Jun 28 13:24:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDF511E80B3 for ; Thu, 28 Jun 2012 13:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.132 X-Spam-Level: X-Spam-Status: No, score=-105.132 tagged_above=-999 required=5 tests=[AWL=1.467, BAYES_00=-2.599, 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 Nra4GUH+wh4s for ; Thu, 28 Jun 2012 13:24:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 63C3611E809F for ; Thu, 28 Jun 2012 13:24:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5SKNUJk004097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jun 2012 13:23:30 -0700 (PDT) Message-ID: <4FECBD42.1070607@isi.edu> Date: Thu, 28 Jun 2012 13:23:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marsh Ray References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> In-Reply-To: <4FECBC1C.9060304@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:24:12 -0000 On 6/28/2012 1:18 PM, Marsh Ray wrote: > On 06/27/2012 10:46 AM, Phillip Hallam-Baker wrote: >> >> I think we need to limit specifications to providing security advice >> and explanations and prohibit security directions. >> >> One reason for this is that the security directions are very >> frequently inappropriate in a real world situation. > > We're talking about IETF internet-oriented protocols. The end-to-end > principle implies that security has to reside in the protocols > implemented at the endpoints because it cannot reside in the network > itself. FWIW, that principle states that hop-by-hop security does not substitute for end-to-end security. It never says that hop-by-hop security isn't useful. Joe From jhutz@cmu.edu Thu Jun 28 13:45:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5897611E80C1 for ; Thu, 28 Jun 2012 13:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJPSf4tC+Z7y for ; Thu, 28 Jun 2012 13:45:23 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id A90D911E80BF for ; Thu, 28 Jun 2012 13:45:23 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q5SKjLU7009351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 16:45:21 -0400 (EDT) From: Jeffrey Hutzelman To: Joe Touch In-Reply-To: <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> Content-Type: text/plain; charset="UTF-8" Date: Thu, 28 Jun 2012 16:45:21 -0400 Message-ID: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: Phillip Hallam-Baker , saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:45:24 -0000 On Thu, 2012-06-28 at 13:23 -0700, Joe Touch wrote: > > On 6/28/2012 1:18 PM, Marsh Ray wrote: > > On 06/27/2012 10:46 AM, Phillip Hallam-Baker wrote: > >> > >> I think we need to limit specifications to providing security advice > >> and explanations and prohibit security directions. > >> > >> One reason for this is that the security directions are very > >> frequently inappropriate in a real world situation. > > > > We're talking about IETF internet-oriented protocols. The end-to-end > > principle implies that security has to reside in the protocols > > implemented at the endpoints because it cannot reside in the network > > itself. > > FWIW, that principle states that hop-by-hop security does not substitute > for end-to-end security. It never says that hop-by-hop security isn't > useful. Actually, the principle we generally mean when we cite "end-to-end" says that _state_ needs to reside in the end nodes, with the network itself being stateless. That makes communication between end nodes resilient to network components discarding (or not having) state, and especially to the notion inherent in a packet-switched network that not every packet will always follow the same path. That principle doesn't necessarily imply that security has to be end-to-end, and it doesn't necessarily apply above the network layer. While it is often "better" for security to be end-to-end, that is not always the case, and it's certainly not essential. As an example, RADIUS' exclusive use of hop-by-hop security has contributed to making it the most successful federated authentication system in the world. -- Jeff From marsh@extendedsubset.com Thu Jun 28 14:38:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA621F84AE for ; Thu, 28 Jun 2012 14:38:05 -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 9XmLVe-h7pow for ; Thu, 28 Jun 2012 14:38:04 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id BE65E21F84A5 for ; Thu, 28 Jun 2012 14:38:04 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SkMPb-000NeI-Pg; Thu, 28 Jun 2012 21:38:03 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7B78B67A3; Thu, 28 Jun 2012 21:38:02 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/pgX1kDLLaW5mbdarYJKKPvhl1f0M9x6A= Message-ID: <4FECCEB6.8020901@extendedsubset.com> Date: Thu, 28 Jun 2012 16:37:58 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:38:06 -0000 On 06/28/2012 03:45 PM, Jeffrey Hutzelman wrote: > > That principle doesn't necessarily imply that security has to be > end-to-end, and it doesn't necessarily apply above the network layer. I don't care if my packets are passed by untrusted routers over untrusted network links. The untrusted network has only ability to blindly DoS my packets by dropping them. So any data integrity or confidentiality I obtain must be provided by systems I "trust", i.e., components I am willing to rely upon. Since the model allows endpoint systems to connect directly to untrusted networks (e.g. public Wifi), the primary security controls must live in the endpoints themselves. > While it is often "better" for security to be end-to-end, that is not > always the case, and it's certainly not essential. As an example, > RADIUS' exclusive use of hop-by-hop security has contributed to making > it the most successful federated authentication system in the world. RADIUS packets are routable but the RADIUS protocol doesn't have the notion of multiple "hops", so we can't meaningfully distinguish hop-by-hop from end-to-end. For security, RADIUS relies upon a shared secret stored at each endpoint. RADIUS can be routed over the internet, but it would be considered bad practice to do that because it would not be acceptably secure to modern standards. It sends the username and almost all attributes other than the password itself in the clear. RADIUS is popular and works great in a datacenter or trusted WAN environment. But it is *not* an example of a good internet security protocol. - Marsh From touch@isi.edu Thu Jun 28 14:59:29 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5777111E80D9 for ; Thu, 28 Jun 2012 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.224 X-Spam-Level: X-Spam-Status: No, score=-105.224 tagged_above=-999 required=5 tests=[AWL=1.375, BAYES_00=-2.599, 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 zwQR25XoEyG3 for ; Thu, 28 Jun 2012 14:59:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id AC34B11E80D0 for ; Thu, 28 Jun 2012 14:59:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5SLwhQN019687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jun 2012 14:58:44 -0700 (PDT) Message-ID: <4FECD393.80103@isi.edu> Date: Thu, 28 Jun 2012 14:58:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:59:29 -0000 On 6/28/2012 1:45 PM, Jeffrey Hutzelman wrote: > On Thu, 2012-06-28 at 13:23 -0700, Joe Touch wrote: >> >> On 6/28/2012 1:18 PM, Marsh Ray wrote: >>> On 06/27/2012 10:46 AM, Phillip Hallam-Baker wrote: >>>> >>>> I think we need to limit specifications to providing security advice >>>> and explanations and prohibit security directions. >>>> >>>> One reason for this is that the security directions are very >>>> frequently inappropriate in a real world situation. >>> >>> We're talking about IETF internet-oriented protocols. The end-to-end >>> principle implies that security has to reside in the protocols >>> implemented at the endpoints because it cannot reside in the network >>> itself. >> >> FWIW, that principle states that hop-by-hop security does not substitute >> for end-to-end security. It never says that hop-by-hop security isn't >> useful. > > Actually, the principle we generally mean when we cite "end-to-end" says > that _state_ needs to reside in the end nodes, with the network itself > being stateless. It's really more that "end to end services cannot be created *solely* through the composition of hop-by-hop services" - that includes state, computation, and message exchanges. FWIW, that doesn't discount the use of hop-by-hop services. They're useful between the hops (consider each hop its own "end" in an end-to-end way), and they can also help make an E2E service more efficient (consider per-hop ARQ, which in some cases can be more efficient than E2E). > That makes communication between end nodes resilient > to network components discarding (or not having) state, and especially > to the notion inherent in a packet-switched network that not every > packet will always follow the same path. A protocol is more than just state. No amount of state will make hop-by-hop security equivalent to end-to-end security because the intermediate nodes see cleartext. > That principle doesn't necessarily imply that security has to be > end-to-end, and it doesn't necessarily apply above the network layer. The principle never says where the ends are, and it definitely applies to all layers. > While it is often "better" for security to be end-to-end, that is not > always the case, and it's certainly not essential. As an example, > RADIUS' exclusive use of hop-by-hop security has contributed to making > it the most successful federated authentication system in the world. See above - hop-by-hop definitely protects the hops, and also can be helpful in E2E performance (e.g., by rejecting things that the hop can discard). Joe From marsh@extendedsubset.com Thu Jun 28 15:02:03 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB7B11E80D9 for ; Thu, 28 Jun 2012 15:02: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=[AWL=0.000, 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 JEZiN3X+yNg4 for ; Thu, 28 Jun 2012 15:02:02 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 851A311E80D0 for ; Thu, 28 Jun 2012 15:02:02 -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 1SkMmn-000IXs-Og; Thu, 28 Jun 2012 22:02:01 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DBB38631F; Thu, 28 Jun 2012 22:02:00 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/LrLUc+63owaK40uATXnAAnXPyXm4BdV8= Message-ID: <4FECD454.5090308@extendedsubset.com> Date: Thu, 28 Jun 2012 17:01:56 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> In-Reply-To: <4FECCEB6.8020901@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:02:03 -0000 On 06/28/2012 04:37 PM, Marsh Ray wrote: > > the RADIUS protocol doesn't have the notion of multiple "hops", I take this back. The RFC 2865 defines a "Proxy-State" attribute http://tools.ietf.org/html/rfc2865 specifically to support the idea of RADIUS proxies introducing multiple hops. However, it also says "Usage of the Proxy-State Attribute is implementation dependent. A description of its function is outside the scope of this specification." In other words, it is an optional free form field available for a RADIUS proxy to use if it wants to. In fact, where I work (PhoneFactor) we make a RADIUS proxy and we do not use this attribute. It was a long time before we encountered any other systems in the field using it. > so we can't meaningfully distinguish hop-by-hop from end-to-end. Because the protocol attaches no semantics this attribute, I think the conclusion is still generally valid. - Marsh From touch@isi.edu Thu Jun 28 15:03:27 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C016C11E80E2 for ; Thu, 28 Jun 2012 15:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.305 X-Spam-Level: X-Spam-Status: No, score=-105.305 tagged_above=-999 required=5 tests=[AWL=1.294, BAYES_00=-2.599, 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 3HVCwsv1El2v for ; Thu, 28 Jun 2012 15:03:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8B11E80D0 for ; Thu, 28 Jun 2012 15:03:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5SM2Z5v020084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Jun 2012 15:02:35 -0700 (PDT) Message-ID: <4FECD47B.2010301@isi.edu> Date: Thu, 28 Jun 2012 15:02:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marsh Ray References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> In-Reply-To: <4FECCEB6.8020901@extendedsubset.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , saag@ietf.org, Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:03:28 -0000 On 6/28/2012 2:37 PM, Marsh Ray wrote: > On 06/28/2012 03:45 PM, Jeffrey Hutzelman wrote: >> >> That principle doesn't necessarily imply that security has to be >> end-to-end, and it doesn't necessarily apply above the network layer. > > I don't care if my packets are passed by untrusted routers over > untrusted network links. The untrusted network has only ability to > blindly DoS my packets by dropping them. It can delay them and reorder them too - both create work for you, depending on your goal. An protected hop allows *anyone* on the path to inject load that can cause your packets to be dropped due to capacity limits. Protected hops reduce that possibility. I.e., this isn't just about protecting you from false packets, but also from protecting the network capacity and infrastructure. E2E security doesn't do either of those two latter things. Joe From aland@deployingradius.com Thu Jun 28 15:46:46 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCCC11E80F3 for ; Thu, 28 Jun 2012 15:46:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7yBGDU3B69E for ; Thu, 28 Jun 2012 15:46:45 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1D11E80F7 for ; Thu, 28 Jun 2012 15:46:45 -0700 (PDT) Message-ID: <4FECDEB8.6030600@deployingradius.com> Date: Thu, 28 Jun 2012 18:46:16 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Marsh Ray References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> In-Reply-To: <4FECCEB6.8020901@extendedsubset.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , saag@ietf.org, Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:46:46 -0000 Marsh Ray wrote: > RADIUS can be routed over the internet, but it would be considered bad > practice to do that because it would not be acceptably secure to modern > standards. It sends the username and almost all attributes other than > the password itself in the clear. All major RADIUS proxying is done via IPSec tunnels. EDUROAM uses RADIUS over TLS. > RADIUS is popular and works great in a datacenter or trusted WAN > environment. But it is *not* an example of a good internet security > protocol. The benefit of RADIUS is that it's simple. This means it's deployed. Deployed security protocols are infinitely better than undeployed ones. e.g. see the uptake of TLS versus IPSec. I won't argue about the protocol complexity, but TLS was absolutely easier to deploy. As a result, it's used to secure all major web sites. IPSec... less so. Alan DeKok. From jis@mit.edu Thu Jun 28 16:04:41 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F8411E80D7 for ; Thu, 28 Jun 2012 16:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.372, 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 0QEAxawKTqFb for ; Thu, 28 Jun 2012 16:04:40 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id A0A6D11E80D3 for ; Thu, 28 Jun 2012 16:04:40 -0700 (PDT) X-AuditID: 12074422-b7f1f6d00000090b-9d-4fece3076eef Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 22.17.02315.703ECEF4; Thu, 28 Jun 2012 19:04:39 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q5SN4dhn001066 for ; Thu, 28 Jun 2012 19:04:39 -0400 Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (authenticated bits=0) (User authenticated as jis@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q5SN4buA015926 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 28 Jun 2012 19:04:39 -0400 (EDT) Received: by dacx6 with SMTP id x6so3621027dac.31 for ; Thu, 28 Jun 2012 16:04:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.233 with SMTP id rf9mr12375227pbc.141.1340924676893; Thu, 28 Jun 2012 16:04:36 -0700 (PDT) Received: by 10.68.48.70 with HTTP; Thu, 28 Jun 2012 16:04:36 -0700 (PDT) In-Reply-To: <4FECBC1C.9060304@extendedsubset.com> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> Date: Thu, 28 Jun 2012 19:04:36 -0400 Message-ID: From: Jeffrey Schiller To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqrcv++I2/wboDWhZT+juZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsbNpPmvBdt6KKW83sDYwfuHqYuTkkBAwkTj46B4rhC0mceHe erYuRi4OIYF9jBKtnzezQDhHGCV6FrSzQjg3mCQuvl/DBNIiJFAq0XrqC5jNKyAocXLmExaI eLFEy5u/zBC2p8T1rX1gNqeAkcS+tduhBm1kljj68hVYgkVAVeLe9kUsEIMCJNpWXGUDsYUF LCVutHaA1bAJqEhse9cCZosIaEh8XL0BbDGzgJXEzx8voGwdiXd9D5ghbG2JZQtfM09gFJ6F 5L5ZSMpmISlbwMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQTIyjA2V2UdjD+ PKh0iFGAg1GJh9eq+42/EGtiWXFl7iFGSQ4mJVFe4btAIb6k/JTKjMTijPii0pzU4kOMEhzM SiK8m6cC5XhTEiurUovyYVLSHCxK4rzXUm76CwmkJ5akZqemFqQWwWRlODiUJHg9HgE1Chal pqdWpGXmlCCkmTg4QYbzAA3/8BBkeHFBYm5xZjpE/hSjMcezt0duMHJM6zlxg1GIJS8/L1VK nFcTZJwASGlGaR7cNFiSesUoDvScMK85SBUPMMHBzXsFtIoJaJVTwGuQVSWJCCmpBsZO+QlV Ut80LLPatC5fsj0047bilFM7Dgp7PRI2ePZwyn2ZgGyHwO0mzSenqU3VjC5wtbVv5RAJSVaZ pWD950TJb7fIZxoTFy+8cYt5/oer042Lq9a/TQyc8JDDy5xh29XgxdNvVC2wumytPOXx5av9 Qg/y5s/U3fnpXf2j1NWe0U99u6829DxVYinOSDTUYi4qTgQACVhuYS0DAAA= Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:04:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jun 28, 2012 at 4:18 PM, Marsh Ray wrote: >> If you are building an email application then maybe the right >> response to an expired certificate is to break. If you are building >> a heart and lung machine or an airplane then your imperative might >> well be to keep the thing running at all costs unless there are >> very good, explicit reasons to shut down. > > > One of these scenarios is far more relevant to the IETF scope than > the other. Don't be too sure. It is hard to know where our work will be deployed. I remember the first time I saw a Boeing 777 cockpit display. Sure looked like it was running the X Window System (and I believe it does). You can bet that the authors of the X Window System were not anticipating that as a usage case at the time they wrote the code. Some code I wrote, a long time ago, for talking to a TELEX machine wound up inside an transformer monitoring application... where it was in the loop for sending messages of the form "transformer about to explode!" -Jeff - -- _______________________________________________________________________ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue =A0Room E17-110A Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu http://jis.qyv.name _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFP7OL98CBzV/QUlSsRAkMzAJ9Cu17BbORchYJdoZTGYsOtsrAAvACgybHe d2wPlgrj6IebrDSowlr/nWo=3D =3DgfF5 -----END PGP SIGNATURE----- From nico@cryptonector.com Thu Jun 28 16:08:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6089611E8088 for ; Thu, 28 Jun 2012 16:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=-1.412, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 x3LhOeKLuQ9h for ; Thu, 28 Jun 2012 16:08:25 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id A751911E80B6 for ; Thu, 28 Jun 2012 16:08:25 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 5DB4A28606F for ; Thu, 28 Jun 2012 16:08:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=BwbhfHNYN+FbMKucVn7GkQQ7G+PaEGGWQWkPZZZTcsdI DxYYGbSbWFhAylSHEvnvG+g4JQhW3EQdAK0kul0j+IETdKm1O8w99D3VZLJSWkq5 REX+/xVL5ur4mLFpF3sRcrZ1BXfDVQ9gvcV2ak2omhDy1Uw0T/4vzDcaVlp3/Ks= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=UuQuokyyV1cqsau4xqKbmyZ5MWY=; b=whH1n7Ccphu 1B7OKJW0lvw5UTBaq6pOGrwnOylLJ5oKnWG4NUypsRGr8FhfmcvNs7ZAsbNanpBm X/4LVLibE9I5bxsEvXA49B/SQ0QE7kXc9c35OgSpNyCA/IDEwj+lwOvdErWcH/px caWngnWK9KnrosIFoJ056qJPOOhXPnPI= Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 2DA3D28605B for ; Thu, 28 Jun 2012 16:08:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2094853vbb.31 for ; Thu, 28 Jun 2012 16:08:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.174.226 with SMTP id bv2mr2460628vdc.32.1340924446064; Thu, 28 Jun 2012 16:00:46 -0700 (PDT) Received: by 10.220.76.203 with HTTP; Thu, 28 Jun 2012 16:00:45 -0700 (PDT) In-Reply-To: <4FECDEB8.6030600@deployingradius.com> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> Date: Thu, 28 Jun 2012 18:00:45 -0500 Message-ID: From: Nico Williams To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:08:26 -0000 On Thu, Jun 28, 2012 at 5:46 PM, Alan DeKok wro= te: > =C2=A0e.g. see the uptake of TLS versus IPSec. =C2=A0I won't argue about = the > protocol complexity, but TLS was absolutely easier to deploy. =C2=A0As a > result, it's used to secure all major web sites. =C2=A0IPSec... less so. Well, yeah, what makes IPsec complex is that it's in such a low layer that it's been difficult (i.e., hasn't happened) to build proper APIs to it. IPsec for end-to-end is dead. There's lots of lessons to draw from our experiences. But I think it's too soon to say that if only we were less stringent about security everything would be better, as some would seem to have it. Interop is king, yes, but let's not throw the security baby out with the bathwater. Nico -- From marsh@extendedsubset.com Thu Jun 28 16:29:03 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEE611E809B for ; Thu, 28 Jun 2012 16:29: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=[AWL=0.000, 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 YerPCAEJTsIe for ; Thu, 28 Jun 2012 16:29:03 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66E21F84B9 for ; Thu, 28 Jun 2012 16:29:03 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SkO91-000ONc-07; Thu, 28 Jun 2012 23:29:03 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1981B64D9; Thu, 28 Jun 2012 23:29:02 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19HU9yckNz3V9H1kc+aL8QbnpaBmgWer4U= Message-ID: <4FECE8BA.5040000@extendedsubset.com> Date: Thu, 28 Jun 2012 18:28:58 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jeffrey Schiller References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:29:04 -0000 On 06/28/2012 06:04 PM, Jeffrey Schiller wrote: > > On Thu, Jun 28, 2012 at 4:18 PM, Marsh Ray > wrote: >> >> One of these scenarios is far more relevant to the IETF scope than >> the other. > > Don't be too sure. It is hard to know where our work will be > deployed. I remember the first time I saw a Boeing 777 cockpit > display. Sure looked like it was running the X Window System (and I > believe it does). You can bet that the authors of the X Window System > were not anticipating that as a usage case at the time they wrote the > code. > > Some code I wrote, a long time ago, for talking to a TELEX machine > wound up inside an transformer monitoring application... where it was > in the loop for sending messages of the form "transformer about to > explode!" Sure, but the point is that the medical, aviation, and power distribution industries each have their own dedicated regulatory bodies precisely because they each have unique and very critical requirements. They are certainly free to use and benefit from IETF standards like anyone else, but they are responsible for re-certifying them to their own purposes. As such, they're probably not great examples to use for thinking about typical IETF standards. Maybe they could even be a little misleading. At the very least, an email delivery operation seems like a better motivating use case. - Marsh From nico@cryptonector.com Thu Jun 28 16:39:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C3D21F85F8 for ; Thu, 28 Jun 2012 16:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 DfGjZN1vnPQD for ; Thu, 28 Jun 2012 16:39:11 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id DEC9721F85FC for ; Thu, 28 Jun 2012 16:39:11 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 818FA6B0078 for ; Thu, 28 Jun 2012 16:39:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=BuhbXj2a9jdldmUi5ODnj uFqfPmgDPaJLIazCqWrIWypvg4lc4/g4INVY1vuMFz6Wlt0MH69H72DEPrboh78V kHP2ZhkK7H95TXF8Vk9yEWj3QWBwzsyt9HY/w2f8oLJQpcV6xdE092uJPQei0ijU v3t/+DVrDIHfW6xxGjnV/w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=m9ZEpfTMQicEKf2xOji/ VPJfq3M=; b=aV/KN+Cie5jl1I+6Znzt+rYOVGYPiz9qurxPADxdoFEs0542VIlN xbahWJrt8boEuLFsVJRjQA81yr2LG2jSjMpreE+lV6RsgsgCzQmM6tNNVhLdzY6e C+wA3maORvDLYCP7JpZMIrA5jIbgC1rswgjCwNUEnHpHZcKXVKkfPhU= Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 5512C6B0070 for ; Thu, 28 Jun 2012 16:39:11 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2105770vcq.31 for ; Thu, 28 Jun 2012 16:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.153.136 with SMTP id k8mr2942557vcw.38.1340926750735; Thu, 28 Jun 2012 16:39:10 -0700 (PDT) Received: by 10.220.76.203 with HTTP; Thu, 28 Jun 2012 16:39:10 -0700 (PDT) In-Reply-To: <4FECE8BA.5040000@extendedsubset.com> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <4FECE8BA.5040000@extendedsubset.com> Date: Thu, 28 Jun 2012 18:39:10 -0500 Message-ID: From: Nico Williams To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Cc: Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:39:12 -0000 On Thu, Jun 28, 2012 at 6:28 PM, Marsh Ray wrote: > On 06/28/2012 06:04 PM, Jeffrey Schiller wrote: >> On Thu, Jun 28, 2012 at 4:18 PM, Marsh Ray >> wrote: >>> One of these scenarios is far more relevant to the IETF scope than >>> the other. >> >> Don't be too sure. It is hard to know where our work will be >> deployed. I remember the first time I saw a Boeing 777 cockpit >> display. Sure looked like it was running the X Window System (and I >> believe it does). You can bet that the authors of the X Window System >> were not anticipating that as a usage case at the time they wrote the >> code. > > Sure, but the point is that the medical, aviation, and power distribution > industries each have their own dedicated regulatory bodies precisely because > they each have unique and very critical requirements. They are certainly > free to use and benefit from IETF standards like anyone else, but they are > responsible for re-certifying them to their own purposes. Too many engineers will just pick something off the shelf. And regulations aren't remotely fail-safe -- too often it's possible to get exemptions from various rules, and I'm sure this applies to many industries. Nico -- From aland@deployingradius.com Thu Jun 28 17:41:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36F11E80E3 for ; Thu, 28 Jun 2012 17:41:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM6Qa7UEURKT for ; Thu, 28 Jun 2012 17:41:24 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DE7C011E80A2 for ; Thu, 28 Jun 2012 17:41:23 -0700 (PDT) Message-ID: <4FECF995.60009@deployingradius.com> Date: Thu, 28 Jun 2012 20:40:53 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 00:41:24 -0000 Nico Williams wrote: > There's lots of lessons to draw from our experiences. But I think > it's too soon to say that if only we were less stringent about > security everything would be better, as some would seem to have it. My point was about ease of use. Being less stringent about security is an orthogonal axis. Given a choice between "mostly" secure but simple, or "very" secure but complex... history shows that the simpler system gets deployed. The complex and "very" secure system largely gets ignored. Alan DeKok. From nico@cryptonector.com Thu Jun 28 17:54:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6D11E80EC for ; Thu, 28 Jun 2012 17:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.295 X-Spam-Level: X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 NMO2GRXgwcOA for ; Thu, 28 Jun 2012 17:54:43 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4668011E809F for ; Thu, 28 Jun 2012 17:54:43 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id C7B742C2058 for ; Thu, 28 Jun 2012 17:54:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=thoXpODf2lEL6tHU/RpSI+KNIe5822gWuXh8B11PeKU5 o1XuqtP0zCUy8NcUJi6tgUiY365SEgwVJVUNyROgJ3Tm8wR4y11/N+EaRY/UYIFT puVtsHY0j4ge8JGZwc5rDzpA6hdCWJB47NpaSzpJ5BWUq70vwPSDUwTt6L9f1Uc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Msh2mbXx3QmKMD1RoXVbveXAyrM=; b=csF7/TIAvbU FkRINAxD4lTydyIYr89RZWSuF1718v6B27i6HqG2pyo5uLZs+QTNx6nFBjDZggEU q+In1nH+UuPY1iYjeYomADWayGwSwSbiSMMe0XfZUwBRJf3RWxH3pF1DtfTv+Sep G6VajGAD8tQb4f3hpZE11eEFkeTVo9gc= Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id A513E2C2057 for ; Thu, 28 Jun 2012 17:54:42 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2134949vcq.31 for ; Thu, 28 Jun 2012 17:54:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.240 with SMTP id o16mr2588064vdg.20.1340931282047; Thu, 28 Jun 2012 17:54:42 -0700 (PDT) Received: by 10.220.76.203 with HTTP; Thu, 28 Jun 2012 17:54:41 -0700 (PDT) In-Reply-To: <4FECF995.60009@deployingradius.com> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> Date: Thu, 28 Jun 2012 19:54:41 -0500 Message-ID: From: Nico Williams To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 00:54:44 -0000 On Thu, Jun 28, 2012 at 7:40 PM, Alan DeKok wro= te: > Nico Williams wrote: >> There's lots of lessons to draw from our experiences. =C2=A0But I think >> it's too soon to say that if only we were less stringent about >> security everything would be better, as some would seem to have it. > > =C2=A0My point was about ease of use. =C2=A0Being less stringent about se= curity > is an orthogonal axis. To a point. Not having to worry at all about security sure makes deployment and use much easier. > =C2=A0Given a choice between "mostly" secure but simple, or "very" secure > but complex... history shows that the simpler system gets deployed. =C2= =A0The > complex and "very" secure system largely gets ignored. Sure, but what's complex about IPsec? IKE + ESP is very similar to TLS in many ways, but I'd argue that the problem there has to do with layering: IP is the wrong layer for security that applications and users care about. While TLS is very much at the right layer, being above TCP. In particular being above TCP means that implementations can be purely in user-land, and they can deal in authenticating user and hostnames/services rather than IP addresses (which are meaningless to users). The point: the complexity of something like IPsec is implied, as opposed to being a question of how its messages are encoded, or what crypto is used. What makes something simple and easy to use may not be obvious. Nico -- From aland@deployingradius.com Fri Jun 29 04:55:33 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A80E21F86FA for ; Fri, 29 Jun 2012 04:55:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpO+WOrFbZrj for ; Fri, 29 Jun 2012 04:55:32 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BCB6421F86B1 for ; Fri, 29 Jun 2012 04:55:31 -0700 (PDT) Message-ID: <4FED979A.9070409@deployingradius.com> Date: Fri, 29 Jun 2012 07:55:06 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 11:55:34 -0000 Nico Williams wrote: > Sure, but what's complex about IPsec? Integrating it, using it. When FreeSWAN was starting, I had a conversation at the Minneapolis Hotel bar: FreeSWAN guy: Hey, you're using Linux, why not IPSec? Me: Here's my laptop with a root shell ... 3 hours later ... FreeSWAN guy: Huh. I can't get it to work. In contrast, OpenSSL is an application library. The API is horrible, but I had a test program up and running in less than an hour. Since then, I do remote administration on occasion. To be polite, IPSec works well when they have a gateway from vendor X, and I use a client from vendor X. For any other combination, the success rate is about 20%. > IKE + ESP is very similar to > TLS in many ways, but I'd argue that the problem there has to do with > layering: IP is the wrong layer for security that applications and > users care about. While TLS is very much at the right layer, being > above TCP. In particular being above TCP means that implementations > can be purely in user-land, and they can deal in authenticating user > and hostnames/services rather than IP addresses (which are meaningless > to users). And the application *knows* it's secure. With IPSec, it's impossible for the application to be sure. From a usability point of view, TLS could very well have been socket options. "Use this client certificate", or "require security". > The point: the complexity of something like IPsec is > implied, as opposed to being a question of how its messages are > encoded, or what crypto is used. What makes something simple and easy > to use may not be obvious. It was pretty obvious to me. Kernel mods? Hard. User-space library? Easy. Alan DeKok. From mouse@Sparkle.Rodents-Montreal.ORG Fri Jun 29 08:22:54 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE4321F8655 for ; Fri, 29 Jun 2012 08:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.801 X-Spam-Level: X-Spam-Status: No, score=-8.801 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 nYPhUfi8uii0 for ; Fri, 29 Jun 2012 08:22:53 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id BAF4021F8657 for ; Fri, 29 Jun 2012 08:22:52 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA16281; Fri, 29 Jun 2012 11:22:51 -0400 (EDT) Date: Fri, 29 Jun 2012 11:22:51 -0400 (EDT) From: Mouse Message-Id: <201206291522.LAA16281@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 29 Jun 2012 11:11:45 -0400 (EDT) To: saag@ietf.org In-Reply-To: <4FED979A.9070409@deployingradius.com> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:22:54 -0000 >> [TLS, as compared to IPsec] > And the application *knows* it's secure. With IPSec, it's impossible > for the application to be sure. To the extent that the latter sentence is true, it's a missing feature in the exported API, something which is entirely fixable. > It was pretty obvious to me. Kernel mods? Hard. User-space > library? Easy. You can do IPsec in userspace too; you just need to, at most, move the rest of the IP stack into userspace along with it. There are already multiple user-space IP stacks (or at least so I'm told, and I find it hard to believe they wouldn't exist, though I've never played with one myself); one of them might be a good place to start if you want to try that. But, really, what's the difference between a userspace library and a kernel mod? Unless you're grubbing around in the internals of whichever one you're using, the major difference is that kernel APIs tend to be better defined and more constrained. (For poorly-tested code, there's also the question of what happens when you tickle a bug, but I consider that a minor issue for the purposes of this discussion.) I think the reason IPsec is harder to use in practice is that it's a good deal more complex; in particular, TLS's solving a significantly smaller problem also means the solution is smaller and simpler. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nico@cryptonector.com Fri Jun 29 09:55:19 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA2021F87F7 for ; Fri, 29 Jun 2012 09:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 TF9p8mBbUX75 for ; Fri, 29 Jun 2012 09:55:18 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0D021F87ED for ; Fri, 29 Jun 2012 09:55:18 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id D08A0318074 for ; Fri, 29 Jun 2012 09:55:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=TU0BFnwrP79JVm58kZASJ6z1MzqX8Bh7bWGpR3Jbfdk5 5GU8e7vHJ7zjJGrne8/NBJxFLEnLw+S0rNoIsUTjlDYgzLkHr7zwG6xnCfQP/EDf dU4omhP8szcSIcKcdk+2X6gNGoiTwK6I0jenuvkC0R8n4TGh5S61pvcdSMFNMJ8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=0ToZBacDnguqViaoLqXIU0ermME=; b=kgIBVXgowfC S4iktvGr0DQ0Ca3ORTJqDr0TNGg/sME+LJNeQhsnDbqILEwZIouF1FUSOyOWYBwy BJCWbYS31puCl3e22k4pAffCa4WJUnE8Isx0QVaNXGdm2U78l0+4EejVclBzrXMw mNCHXtyLmwR3l7bSlncBM9jHPQwMf0Is= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id B8EA531805C for ; Fri, 29 Jun 2012 09:55:17 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4956666pbc.31 for ; Fri, 29 Jun 2012 09:55:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.74.69 with SMTP id r5mr1920760pav.56.1340988917349; Fri, 29 Jun 2012 09:55:17 -0700 (PDT) Received: by 10.142.165.6 with HTTP; Fri, 29 Jun 2012 09:55:17 -0700 (PDT) In-Reply-To: <201206291522.LAA16281@Sparkle.Rodents-Montreal.ORG> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <201206291522.LAA16281@Sparkle.Rodents-Montreal.ORG> Date: Fri, 29 Jun 2012 11:55:17 -0500 Message-ID: From: Nico Williams To: Mouse Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:55:19 -0000 On Fri, Jun 29, 2012 at 10:22 AM, Mouse wrote: >>> [TLS, as compared to IPsec] >> And the application *knows* it's secure. =C2=A0With IPSec, it's impossib= le >> for the application to be sure. > > To the extent that the latter sentence is true, it's a missing feature > in the exported API, something which is entirely fixable. Exactly. There was an effort a few years ago to add IPsec APIs (see BTNS WG), but there was not enough interest. Fifteen or twenty years ago IPsec APIs would have come in handy. Now there's no point. IPsec for end-to-end is dead (just don't tell iSCSI). > But, really, what's the difference between a userspace library and a > kernel mod? =C2=A0[...] Ease of development. Kernel space? -> difficult. Though kernel space forces more discipline, which is good. > I think the reason IPsec is harder to use in practice is that it's a > good deal more complex; in particular, TLS's solving a significantly > smaller problem also means the solution is smaller and simpler. IPsec wants to authenticate IP addresses, which is useless. With APIs it could authenticate whatever identities the apps have credentials for, but there are no IPsec APIs. Other than that IPsec and TLS have equivalent degrees of complexity, particularly when one throws in DTLS. Nico -- From hallam@gmail.com Fri Jun 29 10:17:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F1321F8674 for ; Fri, 29 Jun 2012 10:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 zqiHvWXxfqh8 for ; Fri, 29 Jun 2012 10:17:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 368A821F86F4 for ; Fri, 29 Jun 2012 10:17:39 -0700 (PDT) Received: by yenq13 with SMTP id q13so3289739yen.31 for ; Fri, 29 Jun 2012 10:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X7CC3j+oCZ/blzRpUQO12NJOq0wN78VDzVmq+YUDD/c=; b=yoDeBwCpnHPF5qcZwmy0JcCjgKKCg6gmVeoXMnK7NMYLwbOFjhtpKKV0/Uq+lzNBx/ vJs7jwkFxmjBbgXtpFSHi8MCd9s61ByGqDQeDQmnoJHvSIBuHluA7TrTJ8WxXt5uwkvU RhhslqrPbDUfOorVVkXGT1Qk9ozzGPR9ZkldnsT5Avf9g6pLpcaeJclgnlqFKKpjKsgH FlnVsKU3bd6OqGhZba0rZWS/HyAe49iYmYIhH0u1rVRqyPfTb3r0nu54XHLb6CJ74AdN L792PijW8By6w75yJEeo5FBlyip3loSXEvUIFbbEOILNkTIKQ7zLvQGiaLZ9teHle+sM Dvzg== MIME-Version: 1.0 Received: by 10.236.176.129 with SMTP id b1mr3891820yhm.126.1340990258719; Fri, 29 Jun 2012 10:17:38 -0700 (PDT) Received: by 10.147.33.19 with HTTP; Fri, 29 Jun 2012 10:17:38 -0700 (PDT) In-Reply-To: <1340908573.31047.337.camel@minbar.fac.cs.cmu.edu> References: <9846_1340905422_q5SHhfoJ012996_p06240805cc123b2eeb7e@192.168.1.2> <1340908573.31047.337.camel@minbar.fac.cs.cmu.edu> Date: Fri, 29 Jun 2012 13:17:38 -0400 Message-ID: From: Phillip Hallam-Baker To: Jeffrey Hutzelman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:17:40 -0000 On Thu, Jun 28, 2012 at 2:36 PM, Jeffrey Hutzelman wrote: > On Thu, 2012-06-28 at 12:52 -0400, Stephen Kent wrote: > >> The critical flag is used by a CA to force an RP to reject a cert if >> the extension is marked critical AND the RP does not know how to process >> the extension, period. =A0It's a way for a CA to say "if you can't proce= ss >> (enforce) the data in this extension, I don't want you to rely on this c= ert, >> because I (the CA) believe that the extension is very important to safe >> use of the public key in the cert. > > Or phrased another way, because the extension contains information > restricting the use of the certificate or the public key contained > therein. This is why I used the term 'Conditions' in SAML. SAML conditions are intended to be used in precisely the same way that the X.509v3 critical bit should be used. But I used the term conditions because the conflation of 'critical bit set' and 'important' had been completely unhelpful in PKIX. There is no place in a spec for a 'yes I really mean it' bit. Either the cert issuer means it or they don't. 'Feel free to ignore this if you don't understand' is perfectly acceptable (in SAML terms 'advice'). but a cert issuer should not say something they don't understand and mean. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Fri Jun 29 10:28:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2F21F86D6 for ; Fri, 29 Jun 2012 10:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 B24qkRRI7KDN for ; Fri, 29 Jun 2012 10:28:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E49A21F86D1 for ; Fri, 29 Jun 2012 10:28:12 -0700 (PDT) Received: by yenq13 with SMTP id q13so3301322yen.31 for ; Fri, 29 Jun 2012 10:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DGGBLyPBGnqoNYJ9PkccYtRJ12DWgZLDcdHaGFP1PUg=; b=0jRKjm2k7xCSvhV4KrTaTeVkeX5hgtjIBdkON1Xn0B6tIouwk6QMeEiOW73972sD0l 5TRThPkAH6HFAxl/b3dqZTAA4mKvsGCzpjwJo0d3V2oMeGdnrkIJ1mGRSl7xDVI+6a2z co6eHFOxdb+YWJKPun3hPGXXribDx9FiFqxKukUP0qxVkvLj8Efe8bPb35YlqHLDXx6S z6utVy00Rz4mD2XcXKEtqyk4MDUCF4nlhQgXuF8mYohqil2o3VEmwxAvtN2xZFNx335M O7uD4MeOXBfnuxjCE9fHmqNMD0DbBlYWJYdS0itz4RkNSsd64no5cwSSnAijcrfiexNT KeFg== MIME-Version: 1.0 Received: by 10.101.218.19 with SMTP id v19mr1073364anq.63.1340990891816; Fri, 29 Jun 2012 10:28:11 -0700 (PDT) Received: by 10.147.33.19 with HTTP; Fri, 29 Jun 2012 10:28:11 -0700 (PDT) In-Reply-To: <4FECBC1C.9060304@extendedsubset.com> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> Date: Fri, 29 Jun 2012 13:28:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:28:13 -0000 On Thu, Jun 28, 2012 at 4:18 PM, Marsh Ray wrote: > On 06/27/2012 10:46 AM, Phillip Hallam-Baker wrote: >> >> >> I think we need to limit specifications to providing security advice >> and explanations and prohibit security directions. >> >> One reason for this is that the security directions are very >> frequently inappropriate in a real world situation. > > > We're talking about IETF internet-oriented protocols. The end-to-end > principle implies that security has to reside in the protocols implemented > at the endpoints because it cannot reside in the network itself. That is not the end-to-end principle described by Clark. His proposal was descriptive, not normative. Putting security in the network has certain consequences, putting them at the endpoints has other properties. What a lot of people can't get to grasps with is that end-to-end security really means something is secured from one PERSON or ORANIZATION to another. The concept pre-dates computer systems. So no IETF protocol can ever offer true end-to-end security as we specify protocols, not people. End-to-end is a design choice and it comes with certain costs and certain benefits. Effective real world security designs invariably use multiple layers of security. S/MIME is not going to give you perfect confidentiality (the subject lines are not encrypted for a start), nor is STARTTLS. An effective security solution is going to require both (plus some stuff we don't yet have). I think we have tended to forgo a lot of good enough security that could have been deployed on the Internet because people insisted on 'absolute' which was impractical. It only takes a small practical limitation to render a whole spec useless. For example none of the IPSEC implementations in the platforms was a practical enterprise security solution because they didn't implement the necessary hacks to enable NAT bypass. S/MIME use is crippled by the fact that client certs expire and so on. -- Website: http://hallambaker.com/ From touch@isi.edu Fri Jun 29 13:01:20 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30821F88BF for ; Fri, 29 Jun 2012 13:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.425 X-Spam-Level: X-Spam-Status: No, score=-105.425 tagged_above=-999 required=5 tests=[AWL=1.174, BAYES_00=-2.599, 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 QQQlkq9gqY6V for ; Fri, 29 Jun 2012 13:01:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1B21F886E for ; Fri, 29 Jun 2012 13:01:19 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TK0hha001613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 13:00:43 -0700 (PDT) Message-ID: <4FEE096B.1090602@isi.edu> Date: Fri, 29 Jun 2012 13:00:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alan DeKok References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> In-Reply-To: <4FED979A.9070409@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , saag@ietf.org, Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:01:20 -0000 On 6/29/2012 4:55 AM, Alan DeKok wrote: > Nico Williams wrote: >> Sure, but what's complex about IPsec? > > Integrating it, using it. When FreeSWAN was starting, I had a > conversation at the Minneapolis Hotel bar: > > FreeSWAN guy: Hey, you're using Linux, why not IPSec? > > Me: Here's my laptop with a root shell > > ... 3 hours later ... > > FreeSWAN guy: Huh. I can't get it to work. > > In contrast, OpenSSL is an application library. The API is horrible, > but I had a test program up and running in less than an hour. In contrast, I can shut down your OpenSSL connection by sending RSTs at your TCP connection, where I can't attack a TCP connection protected with either IPsec or TCP-AO (except as a DOS attack on the whole link). SSL/TLS does nothing to protect the transport or network layers. ... >> IKE + ESP is very similar to >> TLS in many ways, but I'd argue that the problem there has to do with >> layering: IP is the wrong layer for security that applications and >> users care about. While TLS is very much at the right layer, being >> above TCP. The "right layer" depends on the threats; if threats don't include direct attacks on your connection, you might be OK with TLS. If not, TLS will do nothing to help. ... > It was pretty obvious to me. Kernel mods? Hard. User-space library? > Easy. It's obvious to me too: Kernel mods - safe and fast. User space mods - unsafe and slow. So you have "easy" but not safe or fast. That means you get people to use it, but not that you're doing a better job protecting things. Joe From ekr@rtfm.com Fri Jun 29 13:13:44 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70D21F88A0 for ; Fri, 29 Jun 2012 13:13:44 -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 vHK--ZyuE1xc for ; Fri, 29 Jun 2012 13:13:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7242021F8888 for ; Fri, 29 Jun 2012 13:13:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2811212vbb.31 for ; Fri, 29 Jun 2012 13:13:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ifKrvPSy/J4D+U1HELjiMjYIYzBarWnHxJEMXzxPLl8=; b=BjfxyzCC4LktTbBK6Wsvt0e8vMu5vH0E9lzuTsOrHi9e8EELApEwz80Mlny/zeZvNH ax9DthWf0noBl4PP89Uv+bNYjiSF/0E2M6Qcce/lxPLI5sFVISq/XAplWwjlIFqc/P5f i2prTuKDWpQA3OQjbmfqdVRpMZE6sZkppY6Dg9QLzD0BmhfkJOEtaouzECiK99U9I0x/ rOEO48iQ+bUjOn+cxsXr3enfChRS3KqsD4Qe0GV6BszE/5K/iDG7MRhhW7a+aeUYjEbg Rpjb1IyEFaASURXnyR72xtehOF8zHZ3kPxIs7s/LPU11VwM5jqUs++U9ahAuiBXNc3Wi hhiQ== Received: by 10.52.99.227 with SMTP id et3mr1433625vdb.110.1341000820880; Fri, 29 Jun 2012 13:13:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 13:13:00 -0700 (PDT) X-Originating-IP: [216.239.55.138] In-Reply-To: <4FEE096B.1090602@isi.edu> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> From: Eric Rescorla Date: Fri, 29 Jun 2012 13:13:00 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnccqKj0JT6eCD86sQdDXaPhLWfbtwuvkEMsAIyB8PthtmJNLW4p0ZBYONxlNGspWj6ACb/ Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:13:44 -0000 On Fri, Jun 29, 2012 at 1:00 PM, Joe Touch wrote: > > > On 6/29/2012 4:55 AM, Alan DeKok wrote: >> >> Nico Williams wrote: >>> >>> Sure, but what's complex about IPsec? >> >> >> =A0 Integrating it, using it. =A0When FreeSWAN was starting, I had a >> conversation at the Minneapolis Hotel bar: >> >> FreeSWAN guy: Hey, you're using Linux, why not IPSec? >> >> Me: Here's my laptop with a root shell >> >> ... 3 hours later ... >> >> FreeSWAN guy: Huh. =A0I can't get it to work. >> >> =A0 In contrast, OpenSSL is an application library. =A0The API is horrib= le, >> but I had a test program up and running in less than an hour. > > > In contrast, I can shut down your OpenSSL connection by sending RSTs at y= our > TCP connection, where I can't attack a TCP connection protected with eith= er > IPsec or TCP-AO (except as a DOS attack on the whole link). This turns out to not be that important a practical issue for most scenario= s, especially for the Web where short connections are the norm. >> =A0 It was pretty obvious to me. =A0Kernel mods? =A0Hard. =A0User-space = library? >> =A0Easy. > > > It's obvious to me too: > > Kernel mods - safe and fast. > > User space mods - unsafe and slow. > > So you have "easy" but not safe or fast. That means you get people to use > it, but not that you're doing a better job protecting things. Why do you think user space is unsafe or slow? -Ekr From huitema@microsoft.com Fri Jun 29 13:33:39 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424AC21F88F0 for ; Fri, 29 Jun 2012 13:33:39 -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 jpa76-+F94iD for ; Fri, 29 Jun 2012 13:33:38 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA121F88ED for ; Fri, 29 Jun 2012 13:33:38 -0700 (PDT) Received: from mail110-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 20:31:47 +0000 Received: from mail110-co1 (localhost [127.0.0.1]) by mail110-co1-R.bigfish.com (Postfix) with ESMTP id 9EB5D20063; Fri, 29 Jun 2012 20:31:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VS-5(zzzz1202hzz8275bh186Mz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail110-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=huitema@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail110-co1 (localhost.localdomain [127.0.0.1]) by mail110-co1 (MessageSwitch) id 1341001905718988_13855; Fri, 29 Jun 2012 20:31:45 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.233]) by mail110-co1.bigfish.com (Postfix) with ESMTP id A3480C40044; Fri, 29 Jun 2012 20:31:45 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 20:31:45 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.121]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Fri, 29 Jun 2012 20:33:32 +0000 From: Christian Huitema To: Eric Rescorla , Joe Touch Thread-Topic: [saag] Should security requirements be MUST? Thread-Index: AQHNVW7vuVPjajRHVUOn7PeVSUS/rJcQQbMAgAATFQCAAAQMgIAAG/uAgAAD24CAALiEAIAAh66AgAADbwCAAAMX0A== Date: Fri, 29 Jun 2012 20:33:30 +0000 Message-ID: References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Phillip Hallam-Baker , "saag@ietf.org" , Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:33:39 -0000 IPSEC and TLS are complementary. They solve different problems, at differen= t layers. Microsoft is using IPSEC extensively for our internal network. The basic ru= le is "you cannot set a TCP connection to one of the computer in the networ= k if you cannot establish an IPSEC connection first." We market that as "se= rvice and domain isolation" (http://technet.microsoft.com/en-us/network/bb5= 45651.aspx). What it does is effectively enforce a big distributed firewall= around the domain's computers, independent of the particularities of netwo= rk wiring and routing. This is one of the layers in the "defense in depth" = approach. But even with IPSEC, we also use TLS, for example if you want to connect to= a high value server. IPSEC is good at preventing undesirable connections f= rom unknown computers. TLS is good at securing application connections from= identified users. And yes, the deployment issues with IPSEC are interesting. Making the solut= ion work fine took a lot of effort. -- Christian Huitema From rbarnes@bbn.com Fri Jun 29 13:34:21 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A58421F8902 for ; Fri, 29 Jun 2012 13:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 yFGm8GAQ9+m3 for ; Fri, 29 Jun 2012 13:34:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9156221F88F6 for ; Fri, 29 Jun 2012 13:34:20 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:55567) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SkhtR-000LYv-HM; Fri, 29 Jun 2012 16:34:17 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Richard L. Barnes" In-Reply-To: Date: Fri, 29 Jun 2012 16:34:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> To: Eric Rescorla X-Mailer: Apple Mail (2.1278) Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:34:21 -0000 /me parachutes into the thread On Jun 29, 2012, at 4:13 PM, Eric Rescorla wrote: > On Fri, Jun 29, 2012 at 1:00 PM, Joe Touch wrote: >>=20 >>=20 >> On 6/29/2012 4:55 AM, Alan DeKok wrote: >>>=20 >>> Nico Williams wrote: >>>>=20 >>>> Sure, but what's complex about IPsec? >>>=20 >>>=20 >>> Integrating it, using it. When FreeSWAN was starting, I had a >>> conversation at the Minneapolis Hotel bar: >>>=20 >>> FreeSWAN guy: Hey, you're using Linux, why not IPSec? >>>=20 >>> Me: Here's my laptop with a root shell >>>=20 >>> ... 3 hours later ... >>>=20 >>> FreeSWAN guy: Huh. I can't get it to work. >>>=20 >>> In contrast, OpenSSL is an application library. The API is = horrible, >>> but I had a test program up and running in less than an hour. >>=20 >>=20 >> In contrast, I can shut down your OpenSSL connection by sending RSTs = at your >> TCP connection, where I can't attack a TCP connection protected with = either >> IPsec or TCP-AO (except as a DOS attack on the whole link). >=20 > This turns out to not be that important a practical issue for most = scenarios, > especially for the Web where short connections are the norm. Will this continue to be the case with WebSockets and/or HTTP/2.0 = (=3D=3DSPDY)? >>> It was pretty obvious to me. Kernel mods? Hard. User-space = library? >>> Easy. >>=20 >>=20 >> It's obvious to me too: >>=20 >> Kernel mods - safe and fast. >>=20 >> User space mods - unsafe and slow. >>=20 >> So you have "easy" but not safe or fast. That means you get people to = use >> it, but not that you're doing a better job protecting things. >=20 > Why do you think user space is unsafe or slow? Why do IP stacks usually reside in the kernel? --Richard= From ekr@rtfm.com Fri Jun 29 13:41:33 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF7321F88F7 for ; Fri, 29 Jun 2012 13:41:33 -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 dHdQ2UFDNNiN for ; Fri, 29 Jun 2012 13:41:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3403321F88A2 for ; Fri, 29 Jun 2012 13:41:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2827406vbb.31 for ; Fri, 29 Jun 2012 13:41:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Jz75/pgXpz+450hgwJGQextVB/GHg/cr6evEO68+4bQ=; b=OOn29pJIgWwj5+v87Dlp86IRk9VFhMcgDj59AdA+4gLNmLaBpPY/ejaRdulQxrvg8O pW4mP156e+AdeyhsQGqEJaL2B0bcRJ1fmvaj3W+ayJ1YoP/gJkua0CiaUNaHMJMATgog c4Q7uh8L7pkBor+0A20XvIMl9MkolI2D3TiP92sjpnMjW/sHxtRJ2M5l68uh/Ozd7rLZ fckoTiFjVH5VWwYQ75ZvBOhYoeCcag0DOdOxHFQDjt8lPAW0LVmw1YgpZgmdWWfZrX1A vYDBKXCCvaGfb+khT5Y1GxfT9AwRG/iKniPazure4G2OqB8Q1gRsDpJ4ABBg+FIhMhxA Ro7g== Received: by 10.221.9.139 with SMTP id ow11mr1783752vcb.26.1341002491704; Fri, 29 Jun 2012 13:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 13:40:51 -0700 (PDT) X-Originating-IP: [216.239.55.138] In-Reply-To: References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> From: Eric Rescorla Date: Fri, 29 Jun 2012 13:40:51 -0700 Message-ID: To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlEyckcGtR4HILII4ORAxOLgKzK7/H4vDTtuJNK8fJsPKzjYrpKCuJfwfjoS2DgivVowbZ+ Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:41:33 -0000 On Fri, Jun 29, 2012 at 1:34 PM, Richard L. Barnes wrote: > /me parachutes into the thread > > On Jun 29, 2012, at 4:13 PM, Eric Rescorla wrote: > >> On Fri, Jun 29, 2012 at 1:00 PM, Joe Touch wrote: >>> >>> >>> On 6/29/2012 4:55 AM, Alan DeKok wrote: >>>> >>>> Nico Williams wrote: >>>>> >>>>> Sure, but what's complex about IPsec? >>>> >>>> >>>> =A0 Integrating it, using it. =A0When FreeSWAN was starting, I had a >>>> conversation at the Minneapolis Hotel bar: >>>> >>>> FreeSWAN guy: Hey, you're using Linux, why not IPSec? >>>> >>>> Me: Here's my laptop with a root shell >>>> >>>> ... 3 hours later ... >>>> >>>> FreeSWAN guy: Huh. =A0I can't get it to work. >>>> >>>> =A0 In contrast, OpenSSL is an application library. =A0The API is horr= ible, >>>> but I had a test program up and running in less than an hour. >>> >>> >>> In contrast, I can shut down your OpenSSL connection by sending RSTs at= your >>> TCP connection, where I can't attack a TCP connection protected with ei= ther >>> IPsec or TCP-AO (except as a DOS attack on the whole link). >> >> This turns out to not be that important a practical issue for most scena= rios, >> especially for the Web where short connections are the norm. > > Will this continue to be the case with WebSockets and/or HTTP/2.0 (=3D=3D= SPDY)? My impression is yes. There are just too many intermediate elements which like to shut stuff down to be able to build an app which can't deal with losing connections, especially on mobile. >> Why do you think user space is unsafe or slow? > > Why do IP stacks usually reside in the kernel? Because they always have? Seriously, the operating systems we are working with were designed in an era where multiprocessing was taken seriously and the job of the kernel was partly to protect one user from another. Hence the restrictions on accessing port 1024, promiscuous mode, and raw IP data transmission unless you are root on UNIX. AFAIK this isn't a performance issue, nor is it really a safety issue from the perspective of the application. -Ekr From mouse@Sparkle.Rodents-Montreal.ORG Fri Jun 29 13:47:14 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEB821F8879 for ; Fri, 29 Jun 2012 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 P9nEqWzzmvoT for ; Fri, 29 Jun 2012 13:47:14 -0700 (PDT) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id DA7B521F8878 for ; Fri, 29 Jun 2012 13:47:13 -0700 (PDT) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA18880; Fri, 29 Jun 2012 16:47:13 -0400 (EDT) Date: Fri, 29 Jun 2012 16:47:13 -0400 (EDT) From: Mouse Message-Id: <201206292047.QAA18880@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 29 Jun 2012 16:40:08 -0400 (EDT) To: saag@ietf.org In-Reply-To: References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:47:14 -0000 >>> Kernel mods - safe and fast. >>> User space mods - unsafe and slow. Calling in-kernel "safe" and userspace "unsafe" betrays an interesting bias with respect to what "safety" is. There are kinds of safety I care about for which userland is substantially safer than the kernel. >> Why do you think user space is unsafe or slow? > Why do IP stacks usually reside in the kernel? Honestly? Because, "usually", the system is a conceptually monolithic kernel that, because of its privilege design, can't really put it anywhere else. Under a microkernel design, rather than the traditional kernel that's commonest these days, the IP stack _is_ in user space. Mouse From touch@isi.edu Fri Jun 29 13:51:31 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91F221F8885 for ; Fri, 29 Jun 2012 13:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.484 X-Spam-Level: X-Spam-Status: No, score=-105.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, 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 moRaufo8QE5Y for ; Fri, 29 Jun 2012 13:51:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEBD21F8880 for ; Fri, 29 Jun 2012 13:51:31 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TKodEA008656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 13:50:39 -0700 (PDT) Message-ID: <4FEE151F.9040209@isi.edu> Date: Fri, 29 Jun 2012 13:50:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:51:32 -0000 On 6/29/2012 1:13 PM, Eric Rescorla wrote: > On Fri, Jun 29, 2012 at 1:00 PM, Joe Touch wrote: ... >> It's obvious to me too: >> >> Kernel mods - safe and fast. >> >> User space mods - unsafe and slow. >> >> So you have "easy" but not safe or fast. That means you get people to use >> it, but not that you're doing a better job protecting things. > > Why do you think user space is unsafe or slow? Kernel based implementations come from the OS manufacturer (ideally), or at least require privilege to modify. Not so for user-space. User-space protocols are not nearly as efficient in dealing with drivers, and can't take advantage of hardware assist in outboard devices. Joe From ekr@rtfm.com Fri Jun 29 14:02:28 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E3311E8073 for ; Fri, 29 Jun 2012 14:02:28 -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 Fbg6l430d3cx for ; Fri, 29 Jun 2012 14:02:27 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD9611E8085 for ; Fri, 29 Jun 2012 14:02:27 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2832339vcq.31 for ; Fri, 29 Jun 2012 14:02:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=7uyUM4DlZT+/HdJFPC7RLcSH2t5jfk0lbZ6DqAaHOrU=; b=W+LbGm3QjMyYctpQBCIno+qELrAFE3iBJaA+vbofhM+cqNMRkM5J/4QGtLTmKEykK9 s5qF/WhUVyvVXkaNZrkktv0bANfbMkw3zkKngruOTeCaVoN7AvIgjbR1SbWnSvFiCwDY tTcVNTuj4OD8JWekStxEwaurRoA7k/7mszjkwcSDUUaUtn2jPoSSEwkx1v/dRrwh+UXs UFEM0xFaGGn4GzNpSXesBOJuXO2X66OCLAOvae6hEXGGXkdQej7w49mBlTMlbKGz5qKK rCGwlFim8QwzLHnajN7s0ew6lBFiWdutXndVQdIfHmitIZVp6SJK1i+HASSTXeNJ1YQq o7kA== Received: by 10.52.22.50 with SMTP id a18mr1521014vdf.60.1341003746965; Fri, 29 Jun 2012 14:02:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 14:01:46 -0700 (PDT) X-Originating-IP: [216.239.55.138] In-Reply-To: <4FEE151F.9040209@isi.edu> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> From: Eric Rescorla Date: Fri, 29 Jun 2012 14:01:46 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm5b8PhxLH3pmz/6mgpuvk1BA/5/F0LNcss/44wBi7Bqdq9VDolhSzuaGfh0pOhwdE+goLZ Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:02:28 -0000 On Fri, Jun 29, 2012 at 1:50 PM, Joe Touch wrote: > > > On 6/29/2012 1:13 PM, Eric Rescorla wrote: >> >> On Fri, Jun 29, 2012 at 1:00 PM, Joe Touch wrote: > > ... > >>> It's obvious to me too: >>> >>> Kernel mods - safe and fast. >>> >>> User space mods - unsafe and slow. >>> >>> So you have "easy" but not safe or fast. That means you get people to use >>> it, but not that you're doing a better job protecting things. >> >> >> Why do you think user space is unsafe or slow? > > > Kernel based implementations come from the OS manufacturer (ideally), or at > least require privilege to modify. Not so for user-space. I don't understand what your threat model is. Say that tomorrow OS/X shipped with an SSL/TLS stack in the kernel. How would this be any more secure from the perspective a SSL/TLS using application, seeing as any attacker who can modify the (formerly) userland stack can modify the application that uses SSL/TLS? > User-space protocols are not nearly as efficient in dealing with drivers, > and can't take advantage of hardware assist in outboard devices. I've written plenty of applications which use crypto accelerators. They just need to have the kernel mediate the interaction. More importantly, for the purposes of crypto (and that's the topic on the table), either it's incredibly CPU intensive, in which case drivers don't matter, or it's really fast, in which case the network is the bottleneck. I don't think I've every seen a crypto-using application on a modern system which woud have its performance significantly improved by being in the kernel. -Ekr From touch@isi.edu Fri Jun 29 14:08:35 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D52421F875D for ; Fri, 29 Jun 2012 14:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.537 X-Spam-Level: X-Spam-Status: No, score=-105.537 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, 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 Y1zUqt27sXvf for ; Fri, 29 Jun 2012 14:08:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0B79121F86C5 for ; Fri, 29 Jun 2012 14:08:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TL7hwv011151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 14:07:43 -0700 (PDT) Message-ID: <4FEE191F.6070902@isi.edu> Date: Fri, 29 Jun 2012 14:07:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:08:35 -0000 Hi, Eric, On 6/29/2012 2:01 PM, Eric Rescorla wrote: > On Fri, Jun 29, 2012 at 1:50 PM, Joe Touch wrote: ... >> Kernel based implementations come from the OS manufacturer (ideally), or at >> least require privilege to modify. Not so for user-space. > > I don't understand what your threat model is. Say that tomorrow OS/X shipped > with an SSL/TLS stack in the kernel. How would this be any more secure > from the perspective a SSL/TLS using application, seeing as any attacker > who can modify the (formerly) userland stack can modify the application > that uses SSL/TLS? That's why SSL/TLS is less secure than IPsec. Userland can't access IP directly without privilege. >> User-space protocols are not nearly as efficient in dealing with drivers, >> and can't take advantage of hardware assist in outboard devices. > > I've written plenty of applications which use crypto accelerators. They > just need to have the kernel mediate the interaction. The kernel needs to make sure that multiple users can share the hardware. That's not typically supported on most outboard protocol accelerators. You can point to an exception perhaps, but it's not the typical case for hardware designers, drivers, or kernel support. > More importantly, for the purposes of crypto (and that's the topic on > the table), either it's incredibly CPU intensive, in which case drivers > don't matter, or it's really fast, in which case the network is the > bottleneck. Or it is slow in software and fast in dedicated accelerator hardware, and the hardware isn't designed to be shared by userspace apps. > I don't think I've every seen a crypto-using application > on a modern system which woud have its performance significantly > improved by being in the kernel. It would if being in the kernel gives it access to hardware that it can't get to otherwise. Joe From ekr@rtfm.com Fri Jun 29 14:14:11 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F5E21F883E for ; Fri, 29 Jun 2012 14:14:11 -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 gbNgeUnxxVTi for ; Fri, 29 Jun 2012 14:14:11 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9321F87EF for ; Fri, 29 Jun 2012 14:14:10 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2838647vcq.31 for ; Fri, 29 Jun 2012 14:14:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=d0dRMstZXY3gpF+dc9ZvNvkqc4pH0q0Guf+7F7eWiLc=; b=RXdYuMse//18crkJkXe5vZYv55F6o4DLEhc3cKqfwQII+3/fOXGCsRi+ZnxHC+oXU1 3HA52BbYEsU727qryxQniC2ogCmnAoGmDuOf7mHG1azGI5eCh2kuHOleKBkNf2AnfTHU z/I40AsOGyudYFdzbDVjMWAhebwKRi7PasAajl6GjyqrlhSbN4UHv8VZTNw0xv1MNP/d CvZxgyqEk1Di2lI7wlCg6avuhIpSoOo8/VifdM99DnU2FwjvvN18+KQ0lnVJqOfOPgk9 aItnK2g25GlHCvrsjx0/iT+KiYbM/7UaVyVJpgENtDCVzGpgb6uzLer0nEjqYHGEMscc fYwA== Received: by 10.52.88.170 with SMTP id bh10mr1562093vdb.11.1341004450302; Fri, 29 Jun 2012 14:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 14:13:30 -0700 (PDT) X-Originating-IP: [216.239.55.138] In-Reply-To: <4FEE191F.6070902@isi.edu> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> From: Eric Rescorla Date: Fri, 29 Jun 2012 14:13:30 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQngNXGoYl0h5EK+KLxCjrPdMES6oTQxq0aoC32SVzRA+UBpCyHFsh3sPxnbbaIC+g+5oCSq Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:14:12 -0000 On Fri, Jun 29, 2012 at 2:07 PM, Joe Touch wrote: > Hi, Eric, > > > On 6/29/2012 2:01 PM, Eric Rescorla wrote: >> >> On Fri, Jun 29, 2012 at 1:50 PM, Joe Touch wrote: > > ... > >>> Kernel based implementations come from the OS manufacturer (ideally), or >>> at >>> least require privilege to modify. Not so for user-space. >> >> >> I don't understand what your threat model is. Say that tomorrow OS/X >> shipped >> with an SSL/TLS stack in the kernel. How would this be any more secure >> from the perspective a SSL/TLS using application, seeing as any attacker >> who can modify the (formerly) userland stack can modify the application >> that uses SSL/TLS? > > > That's why SSL/TLS is less secure than IPsec. Userland can't access IP > directly without privilege. "less secure" is meaningless without a threat model. What threat model are you operating under? >> More importantly, for the purposes of crypto (and that's the topic on >> the table), either it's incredibly CPU intensive, in which case drivers >> don't matter, or it's really fast, in which case the network is the >> bottleneck. > > > Or it is slow in software and fast in dedicated accelerator hardware, and > the hardware isn't designed to be shared by userspace apps. > > >> I don't think I've every seen a crypto-using application >> on a modern system which woud have its performance significantly >> improved by being in the kernel. > > > It would if being in the kernel gives it access to hardware that it can't > get to otherwise. I'd be interested in seeing an actual example where this matters. I can't think of a system where (a) crypto performance was a bottleneck and (b) multiple, noncooperating processes needed to do a lot of crypto such that they would have to share a piece of crypto hardware. Can you point me to such a real-world system? -Ekr From touch@isi.edu Fri Jun 29 14:17:51 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7B21F8726 for ; Fri, 29 Jun 2012 14:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.67 X-Spam-Level: X-Spam-Status: No, score=-105.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, 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 FS3PCiOk-Nd4 for ; Fri, 29 Jun 2012 14:17:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7521F8720 for ; Fri, 29 Jun 2012 14:17:50 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TLHVDH012653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 14:17:31 -0700 (PDT) Message-ID: <4FEE1B6B.2000606@isi.edu> Date: Fri, 29 Jun 2012 14:17:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:17:51 -0000 On 6/29/2012 2:13 PM, Eric Rescorla wrote: ... >>> I don't think I've every seen a crypto-using application >>> on a modern system which woud have its performance significantly >>> improved by being in the kernel. >> >> >> It would if being in the kernel gives it access to hardware that it can't >> get to otherwise. > > I'd be interested in seeing an actual example where this matters. I can't > think of a system where (a) crypto performance was a bottleneck > and (b) multiple, noncooperating processes needed to do a lot of > crypto such that they would have to share a piece of crypto hardware. > > > Can you point me to such a real-world system? You already did - userspace IPsec. Kernel-space IPsec doesn't have that issue. Joe From ekr@rtfm.com Fri Jun 29 14:23:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E450121F86C6 for ; Fri, 29 Jun 2012 14:23:23 -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 zsVJ1ayzVhKC for ; Fri, 29 Jun 2012 14:23:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0FA521F86C5 for ; Fri, 29 Jun 2012 14:23:22 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2843099vcq.31 for ; Fri, 29 Jun 2012 14:23:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=jidsi5HBFnzT/6BnlMNwUzB+I9pgE9LDmXVa+tlfiK0=; b=P5QN+82hVRYT+IMjvkmtl6tGADAr0SAnoCSI5cJdH3IAS6+R3ubPKG3hNITok9kqv4 QtEnsskCjLhNzlP8jJstytd6OVUYB/9FklMA7VEqZHcxxKUfXCRrXYbMAa564g6/kg0t Oy413BbZ6GcvHZQJk3jitCyqNKPbV42rz06ZbM9I+/GZh27LTgjxxP48txzKv+QdsQ0S mMcCYMWzv57OO+wmq6uGl1bCmLz73jYbfeT1RoV643oZ7YvOwL+gBR998dV95lilJ8vU 2I5jo9lToPeVCU2CNKhmO08wT4fSerqpODUyWskOzNbtjMTWev1h0Hs8Y8pSm4L7MH3C aEcg== Received: by 10.52.156.47 with SMTP id wb15mr1602041vdb.53.1341005002340; Fri, 29 Jun 2012 14:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 14:22:41 -0700 (PDT) X-Originating-IP: [216.239.55.138] In-Reply-To: <4FEE1B6B.2000606@isi.edu> References: <4FEA35A8.80201@cs.tcd.ie> <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> From: Eric Rescorla Date: Fri, 29 Jun 2012 14:22:41 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQksGSaUE8BUUrpCHqW6nIkO2mnBAgKCBeqghxGa0tafTYIIt7qDZ9u+tsqa0Ej0oo1WpFv+ Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:23:24 -0000 On Fri, Jun 29, 2012 at 2:17 PM, Joe Touch wrote: > > > On 6/29/2012 2:13 PM, Eric Rescorla wrote: > ... > >>>> I don't think I've every seen a crypto-using application >>>> on a modern system which woud have its performance significantly >>>> improved by being in the kernel. >>> >>> >>> >>> It would if being in the kernel gives it access to hardware that it can't >>> get to otherwise. >> >> >> I'd be interested in seeing an actual example where this matters. I can't >> think of a system where (a) crypto performance was a bottleneck >> and (b) multiple, noncooperating processes needed to do a lot of >> crypto such that they would have to share a piece of crypto hardware. >> >> >> Can you point me to such a real-world system? > > > You already did - userspace IPsec. > > Kernel-space IPsec doesn't have that issue. Crypto performance isn't a bottleneck for essentially any IPsec-using user machine because the processor is so fast compared to the available network resources. Really the only time when crypto performance becomes a bottleneck is concentrators, but in those cases it's just one application process, even if it's a bunch of instances of it. -Ekr From touch@isi.edu Fri Jun 29 14:34:39 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAC821F859B for ; Fri, 29 Jun 2012 14:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.707 X-Spam-Level: X-Spam-Status: No, score=-105.707 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, 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 C1besn9dio8m for ; Fri, 29 Jun 2012 14:34:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97621F856D for ; Fri, 29 Jun 2012 14:34:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TLXvBq015063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 14:33:58 -0700 (PDT) Message-ID: <4FEE1F45.3030209@isi.edu> Date: Fri, 29 Jun 2012 14:33:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:34:39 -0000 On 6/29/2012 2:22 PM, Eric Rescorla wrote: ... > Crypto performance isn't a bottleneck for essentially any IPsec-using > user machine because the processor is so fast compared to the > available network resources. For network speeds under 10Mbps maybe, but then you're tying up part of a CPU too. > Really the only time when crypto > performance becomes a bottleneck is concentrators, but in > those cases it's just one application process, even if it's a bunch > of instances of it. Or servers. Or machines on work connections that use company-based resources. USC has tens of thousands of such machines. That's not trivial. Joe From ekr@rtfm.com Fri Jun 29 14:39:22 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F7311E8080 for ; Fri, 29 Jun 2012 14:39:22 -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 Z4fIO-kMQ5+R for ; Fri, 29 Jun 2012 14:39:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC211E8072 for ; Fri, 29 Jun 2012 14:39:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2857626vbb.31 for ; Fri, 29 Jun 2012 14:39:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=aA1bK04gPvh9qo1P46Y/oy1I9IsIf/Twtk4EnECRtZc=; b=di8qS5MYRI3nCHUeW9d3BHMOvAYTCwH6NFPPF1vYr/oTT8/oulaxkmm4ZHt4hzv0cl 2mhPUtA4nQhvM9aNdmHe5S2sdF35d5BDPS1QUu6zcU/+8NRXFlctwRcScRwqo2TjTQ/G VFwVZ+Lno2u2zezOUSoN+Xio0kioWcJwVcebdOZiSzzNN2C5cgpvlqDADr7AZkiNZ34j FhJ28hl2vrRZAJ+TfZ4/dLeMiGHdrUJDodUM8WOINDndZORr9gXg6xBtjg0cVo07Y6+J o+eNv171WEJ5JYlcilWffQvE3rxk7kALTCoZRh6/HpMSDdDU7x1ZKicZ33NHdyDqymbg pJPA== Received: by 10.52.156.47 with SMTP id wb15mr1619615vdb.53.1341005960418; Fri, 29 Jun 2012 14:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 14:38:40 -0700 (PDT) X-Originating-IP: [216.239.55.138] In-Reply-To: <4FEE1F45.3030209@isi.edu> References: <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> From: Eric Rescorla Date: Fri, 29 Jun 2012 14:38:40 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkisas4t33mBFMg13SwMM2v0K880SnKDw70PSAdl0bozTvs+2ZdicKiZLR8+2fpdYp9g2A2 Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:39:22 -0000 On Fri, Jun 29, 2012 at 2:33 PM, Joe Touch wrote: > > > On 6/29/2012 2:22 PM, Eric Rescorla wrote: > ... >> >> Crypto performance isn't a bottleneck for essentially any IPsec-using >> >> user machine because the processor is so fast compared to the >> available network resources. > > > For network speeds under 10Mbps maybe, but then you're tying up part of a > CPU too. What kind of processer are you using, a Z80? My Macbook Air does 800 Mb/s of AES on one core. >> Really the only time when crypto >> >> performance becomes a bottleneck is concentrators, but in >> those cases it's just one application process, even if it's a bunch >> of instances of it. > > > Or servers. Most servers have one dominant kind of traffic they generate and even if you can't share the crypto resources (which I'm not conceding, btw), that type of traffic can get it. > Or machines on work connections that use company-based > resources. I don't see what "work connections" has to do with it. Do you have any actual measurements of crypto load on some real-world traffic profile that supports this argument? -Ekr From tytso@thunk.org Fri Jun 29 15:59:00 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1451421F867D for ; Fri, 29 Jun 2012 15:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, IP_NOT_FRIENDLY=0.334] 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 79ba5TrNsrz7 for ; Fri, 29 Jun 2012 15:58:59 -0700 (PDT) Received: from imap.thunk.org (li9-11.members.linode.com [67.18.176.11]) by ietfa.amsl.com (Postfix) with ESMTP id 962EE21F856D for ; Fri, 29 Jun 2012 15:58:58 -0700 (PDT) Received: from root (helo=tytso-glaptop.cam.corp.google.com) by imap.thunk.org with local-esmtp (Exim 4.72) (envelope-from ) id 1Skk9O-00016x-2V; Fri, 29 Jun 2012 22:58:54 +0000 Received: from tytso by tytso-glaptop.cam.corp.google.com with local (Exim 4.71) (envelope-from ) id 1Skk9O-0005so-Tt; Fri, 29 Jun 2012 18:58:54 -0400 Date: Fri, 29 Jun 2012 18:58:54 -0400 From: Ted Ts'o To: Mouse Message-ID: <20120629225854.GA22347@thunk.org> References: <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <201206291522.LAA16281@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201206291522.LAA16281@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 22:59:00 -0000 On Fri, Jun 29, 2012 at 11:22:51AM -0400, Mouse wrote: > > But, really, what's the difference between a userspace library and a > kernel mod? Unless you're grubbing around in the internals of > whichever one you're using, the major difference is that kernel APIs > tend to be better defined and more constrained. (For poorly-tested > code, there's also the question of what happens when you tickle a bug, > but I consider that a minor issue for the purposes of this discussion.) One of the problems, which was recognized back when I was the IPSEC chair, althouh we were never able to do anything about it, was the bias that "IETF doesn't do API's"; in many ways the GSSAPI was the exception which proved the rule. Part of the problem was not just the institutional bias, but also the fact that most IETF attendees back then (I can't really speak for now) didn't have API design as one of their strengths / core competencies. If we had designed a IPSEC API, much like the BSD Sockets layer was a defacto standard API to TCP/IP, I think it would have done a lot to help the situation. That would have meant exposing things like x509 certificate names in a sane, easy-to-use, and platform independent way via C bindings, which IMHO is still an unsolved problem, it would have made it a lot easier for applications to use IPSEC for end-to-end authentication. There still would have been major deployment challenges, and this might have not been enough (TLS still would have been easier from a deployment perspective, which is really important if you are an application provider/vendor), but IPSEC as an end-to-end application security mechanism would have at least had a fighting chance. - Ted From nico@cryptonector.com Fri Jun 29 16:21:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F27911E8072 for ; Fri, 29 Jun 2012 16:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=-1.536, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=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 8gywXpDHTpme for ; Fri, 29 Jun 2012 16:21:11 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C90F521F864C for ; Fri, 29 Jun 2012 16:21:11 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 1A01A6B007B for ; Fri, 29 Jun 2012 16:21:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:cc:content-type: content-transfer-encoding; q=dns; s=cryptonector.com; b=Yem01xlT /Cqi6QZ6K1RLzHeDP48l60LSDONKxqH8nA78H3LmKIuCT5RuTiXyrUEW5ptCO4Lm DroGIkEXkS+AcUogeEHjcrpLlnSasXYEz91wnBVcwEFgl0aH7/65kaxeeFHrsBD2 iUgdOdQh/iUxe2c8di+4iB3Nf3IDM+C6lyg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type: content-transfer-encoding; s=cryptonector.com; bh=oSjnBoGudsvXJl P81f59ewRsQYU=; b=LX8VsagzHyrbB6YYQO0IEpvIOr/DUR0W8imsmBTPdwAk78 pfQSzJab/ngD+zSEJk6JMBRjVfk/Jexn81NZjRiBou1FWuApllo+Wvm5YO9b0mjH 1IdiYujG/TgrO8Pr3cHS2mDHBb1Uvm9GgaKAKBB+GkUpa6+loJSg/7dabGwao= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 0933A6B0070 for ; Fri, 29 Jun 2012 16:21:11 -0700 (PDT) Received: by dacx6 with SMTP id x6so5163220dac.31 for ; Fri, 29 Jun 2012 16:21:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.39 with SMTP id pt7mr10643504pbc.40.1341012070632; Fri, 29 Jun 2012 16:21:10 -0700 (PDT) Received: by 10.142.165.6 with HTTP; Fri, 29 Jun 2012 16:21:10 -0700 (PDT) Date: Fri, 29 Jun 2012 18:21:10 -0500 Message-ID: From: Nico Williams To: "Ted Ts'o" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 23:21:13 -0000 On Fri, Jun 29, 2012 at 5:58 PM, Ted Ts'o wrote: > > One of the problems, which was recognized back when I was the IPSEC > chair, althouh we were never able to do anything about it, was the > bias that "IETF doesn't do API's"; in many ways the GSSAPI was the > exception which proved the rule. =C2=A0Part of the problem was not just t= he > institutional bias, but also the fact that most IETF attendees back > then (I can't really speak for now) didn't have API design as one of > their strengths / core competencies. That is changing now, but there's still a lot of resistance to APIs. SCTP is another exception to the old bias. > If we had designed a IPSEC API, much like the BSD Sockets layer was a > defacto standard API to TCP/IP, I think it would have done a lot to > help the situation. =C2=A0That would have meant exposing things like x509 > certificate names in a sane, easy-to-use, and platform independent way > via C bindings, which IMHO is still an unsolved problem, it would have > made it a lot easier for applications to use IPSEC for end-to-end > authentication. x.500 naming is just not useful. Humans can handle name@domain and only slightly more complex name forms, but x.500 is impossible. And we're stuck with Name because that's what TBSCertificate uses for subjectName. We can't switch to GeneralName for subjectName. We're screwed. I'm tempted to propose the use of UUIDs in subjectName and then treat the first subjectAltName as the canonical name, banning the use of Name, but that wouldn't fly either. We're stuck. > There still would have been major deployment challenges, and this > might have not been enough (TLS still would have been easier from a > deployment perspective, which is really important if you are an > application provider/vendor), but IPSEC as an end-to-end application > security mechanism would have at least had a fighting chance. Yes. We have taken one step in the direction of making IPsec usable for e2e, namely we've defined a notion of "IPsec channel" (which is much subtler than one might think due to the fact that IPsec deals with in-practice-changeable IP addresses while apps deal in other things. See RFC5660. The idea was that then we could have socket options for doing such things as asking what the "name" (cert, whatever) of the end-points of a socket are, specifying credentials to use on the local side, specifying what a server's name must be or trust anchors, say, what cipher suites to use, etcertera. But interest flagged. The fact is that it's too late for IPsec. There are very few Internet applications that only support the use of IPsec for end-to-end session cryptographic protection (iSCSI, I'm looking at you!), and chances are there won't be any more. Nico -- From touch@isi.edu Fri Jun 29 16:51:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CCE11E8085 for ; Fri, 29 Jun 2012 16:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV-8baEDAbVi for ; Fri, 29 Jun 2012 16:51:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A18E711E8079 for ; Fri, 29 Jun 2012 16:51:04 -0700 (PDT) Received: from [207.151.140.53] ([207.151.140.53]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TNoH1R004126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 16:50:26 -0700 (PDT) Message-ID: <4FEE3F39.5020000@isi.edu> Date: Fri, 29 Jun 2012 16:50:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 23:51:05 -0000 On 6/29/2012 2:38 PM, Eric Rescorla wrote: ... >> For network speeds under 10Mbps maybe, but then you're tying up part of a >> CPU too. > > What kind of processer are you using, a Z80? My Macbook Air does 800 Mb/s of > AES on one core. It also matters for cellphones and even sensor nets. >>> Really the only time when crypto >>> performance becomes a bottleneck is concentrators, but in >>> those cases it's just one application process, even if it's a bunch >>> of instances of it. >> >> >> Or servers. > > Most servers have one dominant kind of traffic they generate > and even if you can't share the crypto resources (which I'm > not conceding, btw), that type of traffic can get it. Everything is a server in some systems. >> Or machines on work connections that use company-based >> resources. > > I don't see what "work connections" has to do with it. Most people's workplaces have a higher bottleneck BW than home or coffee shops. And the rest of the world includes home connections in excess of several hundred Mbps, which can easily swamp a modern CPU's resources. > Do you have any actual measurements of crypto load on some > real-world traffic profile that supports this argument? My last graphed measurements of this were in an NPSEC 2006 paper, and show that an entire Xeon CPU (within noise of current ones) gets around 50Mbps at 100% load. Joe From aland@deployingradius.com Fri Jun 29 17:01:30 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7649A11E8079 for ; Fri, 29 Jun 2012 17:01:30 -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=[AWL=0.000, 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 pgzfAsLRNK-R for ; Fri, 29 Jun 2012 17:01:30 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DFD3311E8072 for ; Fri, 29 Jun 2012 17:01:29 -0700 (PDT) Message-ID: <4FEE41BB.3050705@deployingradius.com> Date: Fri, 29 Jun 2012 20:00:59 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Joe Touch References: <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> In-Reply-To: <4FEE3F39.5020000@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , saag@ietf.org, Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 00:01:30 -0000 Joe Touch wrote: > My last graphed measurements of this were in an NPSEC 2006 paper, and > show that an entire Xeon CPU (within noise of current ones) gets around > 50Mbps at 100% load. Well... I've measured commodity systems doing 940+ Mbps with AES-256. This is in the last 4 months, using 2 year-old systems, and 1.5K packets. If you need crypto acceleration to fill a 1G pipe, then your system has less CPU power than my iPhone. Alan DeKok. From touch@isi.edu Fri Jun 29 17:12:16 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865DA11E8072 for ; Fri, 29 Jun 2012 17:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 QFmUV-UhgUxV for ; Fri, 29 Jun 2012 17:12:15 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7906E11E8096 for ; Fri, 29 Jun 2012 17:12:15 -0700 (PDT) Received: from [207.151.140.53] ([207.151.140.53]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q5U0BjBw015892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 17:11:48 -0700 (PDT) Message-ID: <4FEE4442.70208@isi.edu> Date: Fri, 29 Jun 2012 17:11:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alan DeKok References: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> In-Reply-To: <4FEE41BB.3050705@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Phillip Hallam-Baker , saag@ietf.org, Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 00:12:16 -0000 On 6/29/2012 5:00 PM, Alan DeKok wrote: > Joe Touch wrote: >> My last graphed measurements of this were in an NPSEC 2006 paper, and >> show that an entire Xeon CPU (within noise of current ones) gets around >> 50Mbps at 100% load. > > Well... I've measured commodity systems doing 940+ Mbps with AES-256. > This is in the last 4 months, using 2 year-old systems, and 1.5K packets. It would be useful to know if that actually sent packets on the wire (not in-memory measurements), and if so, how much of your CPU was gone in the process. > If you need crypto acceleration to fill a 1G pipe, then your system > has less CPU power than my iPhone. Your iPhone certainly can't run anywhere this fast. Joe From touch@isi.edu Fri Jun 29 17:22:25 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD64411E8096 for ; Fri, 29 Jun 2012 17:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 bDx9k6-aqda4 for ; Fri, 29 Jun 2012 17:22:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 489C911E8085 for ; Fri, 29 Jun 2012 17:22:25 -0700 (PDT) Received: from [207.151.140.53] ([207.151.140.53]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q5U0LpQP015296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 17:22:01 -0700 (PDT) Message-ID: <4FEE469F.3070405@isi.edu> Date: Fri, 29 Jun 2012 17:21:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Ted Ts'o" References: <4FECBC1C.9060304@extendedsubset.com> <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <201206291522.LAA16281@Sparkle.Rodents-Montreal.ORG> <20120629225854.GA22347@thunk.org> In-Reply-To: <20120629225854.GA22347@thunk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 00:22:25 -0000 Hi, Ted, On 6/29/2012 3:58 PM, Ted Ts'o wrote: ... > One of the problems, which was recognized back when I was the IPSEC > chair, althouh we were never able to do anything about it, was the > bias that "IETF doesn't do API's"; Except that the best protocols we have - TCP being a good example - included APIs in their definition. The sockets API in Unix is basically a direct implementation of the user interface specified in RFC 793. It's not too late to do such an API, IMO. Or at least better late than never. Joe From joelja@bogus.com Fri Jun 29 17:37:37 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354BD21F8599 for ; Fri, 29 Jun 2012 17:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 jTnRC2406yBg for ; Fri, 29 Jun 2012 17:37:36 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B09AB21F857D for ; Fri, 29 Jun 2012 17:37:36 -0700 (PDT) Received: from joels-MacBook-Air.local (48.sub-166-250-32.myvzw.com [166.250.32.48]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q5U0bVAh065131 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 30 Jun 2012 00:37:32 GMT (envelope-from joelja@bogus.com) Message-ID: <4FEE4A45.9040203@bogus.com> Date: Fri, 29 Jun 2012 17:37:25 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: Eric Rescorla References: <27277_1340915064_q5SKONx9008246_4FECBD42.1070607@isi.edu> <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 30 Jun 2012 00:37:32 +0000 (UTC) Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , saag@ietf.org Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 00:37:37 -0000 On 6/29/12 2:38 PM, Eric Rescorla wrote: > On Fri, Jun 29, 2012 at 2:33 PM, Joe Touch wrote: >> >> On 6/29/2012 2:22 PM, Eric Rescorla wrote: >> ... >>> Crypto performance isn't a bottleneck for essentially any IPsec-using >>> >>> user machine because the processor is so fast compared to the >>> available network resources. >> >> For network speeds under 10Mbps maybe, but then you're tying up part of a >> CPU too. > What kind of processer are you using, a Z80? My Macbook Air does 800 Mb/s of > AES on one core. I find the "we have an application for a processor too slow to use crypto" argument to be a little bothersome. contact-less rfid tags have crypto engines on them. motorola 68020's run ssh acceptably for some use cases. the performance envelope of low power embedded controllers that exist now and into the future is sufficient to support crypto at rates necessary to meet application requirement's in many cases and where it is not is not itself a justification for not pushing the stack and the applications in that direction. There are more devices in the future than in the past. From ekr@rtfm.com Fri Jun 29 17:43:13 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5B011E809A for ; Fri, 29 Jun 2012 17:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 JINi70myGJzt for ; Fri, 29 Jun 2012 17:43:13 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB111E80BD for ; Fri, 29 Jun 2012 17:43:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3666809ggn.31 for ; Fri, 29 Jun 2012 17:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=KpCYQzjvLBjWg3T73vCtvMB4xx3eHvSNIaXb+7IWbGo=; b=igg/3jPL3f6SvKcjAww2BplKdU9/by+1fbvAiZGsA3jKL9eaoPeKw2m1eGmiNPObe5 Ctx1jjkv1S9pISytO8QAhTHCEmoIliS94Qkjd910XriimD2pYdmXs9mDpXx9ffpXGSz+ h2wx/A2TI1dWNIFUm3GGeOkxifBVeWxeiRf5TH8mHwLU7T6I2OzZzYUwN7QkJ7NpeQz0 9Fo9LWwee9IcywncTE1MwQwkRyWcSdApssMuBQPP6YU3/UMuet9OD0TchU/24ob5Thry m3sswMyf+VTcvYInQDfK/05cNf/lrnwFQ4TmSdO9vjVwYkKAqu1Cq4wq7n9ixu751aeY B5IA== Received: by 10.42.66.2 with SMTP id n2mr2054910ici.32.1341016991532; Fri, 29 Jun 2012 17:43:11 -0700 (PDT) Received: from [192.168.145.62] ([216.239.55.138]) by mx.google.com with ESMTPS id vi7sm3135488igb.1.2012.06.29.17.43.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 17:43:10 -0700 (PDT) References: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FEE4442.70208@isi.e du> In-Reply-To: <4FEE4442.70208@isi.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Eric Rescorla Date: Fri, 29 Jun 2012 17:43:06 -0700 To: Joe Touch X-Gm-Message-State: ALoCoQnzbcprBE4fscw/P61Bj9g1EEItOIo9XmkMAovZxkE5q+jK+AwkZMC/vjhTEKiCzSnzB//6 Cc: Jeffrey Hutzelman , Phillip Hallam-Baker , "saag@ietf.org" Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 00:43:13 -0000 On Jun 29, 2012, at 17:11, Joe Touch wrote: >=20 >=20 > On 6/29/2012 5:00 PM, Alan DeKok wrote: >> Joe Touch wrote: >>> My last graphed measurements of this were in an NPSEC 2006 paper, and >>> show that an entire Xeon CPU (within noise of current ones) gets around >>> 50Mbps at 100% load. >>=20 >> Well... I've measured commodity systems doing 940+ Mbps with AES-256. >> This is in the last 4 months, using 2 year-old systems, and 1.5K packets= . >=20 > It would be useful to know if that actually sent packets on the wire (not i= n-memory measurements), and if so, how much of your CPU was gone in the proc= ess. >=20 >> If you need crypto acceleration to fill a 1G pipe, then your system >> has less CPU power than my iPhone. >=20 > Your iPhone certainly can't run anywhere this fast. You realize that an iPhone only allows one foreground process so it hardly m= atters if it doesn't share the hardware encryption chip (if there even is on= e) Ekr > Joe From aland@deployingradius.com Sat Jun 30 05:19:24 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7727321F8617 for ; Sat, 30 Jun 2012 05:19:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKypcYzKkvfG for ; Sat, 30 Jun 2012 05:19:24 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BD63221F8615 for ; Sat, 30 Jun 2012 05:19:21 -0700 (PDT) Message-ID: <4FEEEEAA.3090601@deployingradius.com> Date: Sat, 30 Jun 2012 08:18:50 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Joe Touch References: <1340916321.31047.353.camel@minbar.fac.cs.cmu.edu> <4FECCEB6.8020901@extendedsubset.com> <4FECDEB8.6030600@deployingradius.com> <4FECF995.60009@deployingradius.com> <4FED979A.9070409@deployingradius.com> <4FEE096B.1090602@isi.edu> <4FEE151F.9040209@isi.edu> <4FEE191F.6070902@isi.edu> <4FEE1B6B.2000606@isi.edu> <4FEE1F45.3030209@isi.edu> <4FEE3F39.5020000@isi.edu> <4FEE41BB.3050705@deployingradius.com> <4FEE4442.70208@isi.e du> In-Reply-To: <4FEE4442.70208@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , saag@ietf.org, Jeffrey Hutzelman Subject: Re: [saag] Should security requirements be MUST? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 12:19:24 -0000 Joe Touch wrote: > It would be useful to know if that actually sent packets on the wire > (not in-memory measurements), If your best counter-argument is to assume I'm a complete idiot, that explains why your tests only get 50Mbps. For more reality-based counter-arguments, see the "high performance SSH" patches. They're also getting better than 900Mbps with crypto on commodity hardware. Alan DeKok. From yaronf.ietf@gmail.com Sat Jun 30 06:04:47 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09C21F862A for ; Sat, 30 Jun 2012 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 6PJRLBI-b9gV for ; Sat, 30 Jun 2012 06:04:46 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D85FC21F8611 for ; Sat, 30 Jun 2012 06:04:45 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1485717wib.13 for ; Sat, 30 Jun 2012 06:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=F4ODcC/44dvTPhVGpFgSaheqsSZf9aswuMNnhZlhavs=; b=VTr8Cunuij8XFYmpdyrixkrgS0crS4JOziCtH49YBbzIHOAFq3Y7zjiz+QQvmqmcmG UCB2CHFZetK3VcTRRx8GQJ+MHIyZke+m13pBFAEVXDFNMYMpDb86SlR7a6V/WrVnBZnN KX9ngZsm7Qu1zDF1DJvwKauuLhkm3pfB8kglmbcfrcIhOGnhMz3cbksFqv79OoONYjyu aNxj8S0Si0iXGN/gAKNtIwk7V+S0jYo+1tYS8aWXFqfl5hZL+zDUeGtBS8rMEDFP3qvV 3W87UBYKzoiYzHrkhl/5wQD4wmguUeca/FclAYhG+tzGbNaBbycqTyLsI+141bXlKoxU Bd7w== Received: by 10.216.208.221 with SMTP id q71mr2406702weo.174.1341061485584; Sat, 30 Jun 2012 06:04:45 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-181-179-177.red.bezeqint.net. [79.181.179.177]) by mx.google.com with ESMTPS id n6sm21375005wie.7.2012.06.30.06.04.43 (version=SSLv3 cipher=OTHER); Sat, 30 Jun 2012 06:04:45 -0700 (PDT) Message-ID: <4FEEF96A.5050105@gmail.com> Date: Sat, 30 Jun 2012 16:04:42 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 13:04:47 -0000 This is highly speculative, highly subjective of course, but I don't think an API would have gotten IPsec to dominate the world. On the contrary, app developers are happy to focus on their own stuff and not spend too much time on security. From an application point of view, TLS has two important advantages over IPsec (IKE really): - The well known advantage is that TLS is usually happy to authenticate only the server, leaving client auth to the application. This makes deployment so much easier. - The dirty little secret is that many people do not even authenticate the server. In the cloud computing space (today's Wild West?) I have seen several cases of popular tools that just don't bother, with no apparent justification that I can think of. Another example is EAP-TLS configuration on Windows. I'm not trying to imply that TLS is insecure. But clearly if widespread deployment is a goal (and it should be, otherwise why bother writing RFCs) you should let deployers/developers choose their appropriate level of security. In some cases, sadly, they will make the wrong choice. Thanks, Yaron On 06/30/2012 02:21 AM, Nico Williams wrote: > On Fri, Jun 29, 2012 at 5:58 PM, Ted Ts'o wrote: >> >> One of the problems, which was recognized back when I was the IPSEC >> chair, althouh we were never able to do anything about it, was the >> bias that "IETF doesn't do API's"; in many ways the GSSAPI was the >> exception which proved the rule. Part of the problem was not just the >> institutional bias, but also the fact that most IETF attendees back >> then (I can't really speak for now) didn't have API design as one of >> their strengths / core competencies. > > That is changing now, but there's still a lot of resistance to APIs. > SCTP is another exception to the old bias. > >> If we had designed a IPSEC API, much like the BSD Sockets layer was a >> defacto standard API to TCP/IP, I think it would have done a lot to >> help the situation. That would have meant exposing things like x509 >> certificate names in a sane, easy-to-use, and platform independent way >> via C bindings, which IMHO is still an unsolved problem, it would have >> made it a lot easier for applications to use IPSEC for end-to-end >> authentication. > > x.500 naming is just not useful. Humans can handle name@domain and > only slightly more complex name forms, but x.500 is impossible. And > we're stuck with Name because that's what TBSCertificate uses for > subjectName. We can't switch to GeneralName for subjectName. We're > screwed. I'm tempted to propose the use of UUIDs in subjectName and > then treat the first subjectAltName as the canonical name, banning the > use of Name, but that wouldn't fly either. We're stuck. > >> There still would have been major deployment challenges, and this >> might have not been enough (TLS still would have been easier from a >> deployment perspective, which is really important if you are an >> application provider/vendor), but IPSEC as an end-to-end application >> security mechanism would have at least had a fighting chance. > > Yes. We have taken one step in the direction of making IPsec usable > for e2e, namely we've defined a notion of "IPsec channel" (which is > much subtler than one might think due to the fact that IPsec deals > with in-practice-changeable IP addresses while apps deal in other > things. See RFC5660. The idea was that then we could have socket > options for doing such things as asking what the "name" (cert, > whatever) of the end-points of a socket are, specifying credentials to > use on the local side, specifying what a server's name must be or > trust anchors, say, what cipher suites to use, etcertera. But > interest flagged. The fact is that it's too late for IPsec. There > are very few Internet applications that only support the use of IPsec > for end-to-end session cryptographic protection (iSCSI, I'm looking at > you!), and chances are there won't be any more. > > Nico > -- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >