From nobody Mon Jan 7 22:57:35 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430061310F7 for ; Mon, 7 Jan 2019 22:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpGiZ5IaIurT for ; Mon, 7 Jan 2019 22:57:23 -0800 (PST) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C66C130DD7 for ; Mon, 7 Jan 2019 22:57:23 -0800 (PST) Received: by mail-yw1-xc33.google.com with SMTP id n21so1142023ywd.10 for ; Mon, 07 Jan 2019 22:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=Sf2pZ3pdeQfkf+gy/fH8gkNQKkYY5nJdkB+P74A5Pf8=; b=m1RLxQ03Nz6I+ougoKS6J2H0XwBP9zHkjRg1Bbu247oLk7miv62QhMKJsVf9RFB0BB L+GBvfabifeobkjwTHuXcbIrv5vDvXX4amVtfyGaIXRCybLWa1JRMM2NL5IS9hlEAJIU /lZHpq44Ns3RQIwHPiQ2KbVJSVwbed40IivTwL7/gJQw/NfJHSmTGzy2TnOJj9lWeKum JH+FQSleWgWmOmvOGJgp1dnlV6Qp3PrRi0petBuXyQ1gIXOZ6EImHFgePjzqp4JIFFwb ckQGgIjUSPRvGTpBDxpMSzE/cnk+a8f3yPwzLERm4qrzxwW8QpYKm0/3Vz90bQ5bw/tn kbSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=Sf2pZ3pdeQfkf+gy/fH8gkNQKkYY5nJdkB+P74A5Pf8=; b=GwxhzedPRoA4D3KbV+Np20vo3C5PPWaRFIHo61A9jyHI9Zumy/mcSklcrcZAEBJ18p OHF/pNjqTiwvaFITFPd0yDTY+bSA/Qx3Rs341sd12vtA5qK4WF2EkXd1wyG25xpdOX3f tB7obo2gpdV8lcoM/z26yGo93ZHwYaoAZ0QfBvqC6diavXtbvPiyuKhIcRCSQwMZuC9K YCE9QkCOdb/v8z+NOzHqKkzJUb69Czla3DViVgmimb/AKXvtSG26nXh80Qeu/8ShU1bG R9dmTPPhS3K4P+qtz2qRncTCftHEFeXpJc2e9oWKnkjOwCwOyThnW1res8aptl1wU872 VKgw== X-Gm-Message-State: AJcUukdppjDgZikhkqsAOxI81vc8CSTd8e1BLim58jLPvGAyD1Is/q0O jz6nTxqA/bPuuF2BnCQs6VijcUu7 X-Google-Smtp-Source: ALg8bN6s6A55eOCwFqM/6LQut92pmrJaxw+XezglUeES5kOJ0+zok05dGBCcvnGit39bhuMtMauajA== X-Received: by 2002:a0d:ec86:: with SMTP id v128mr438258ywe.429.1546930642401; Mon, 07 Jan 2019 22:57:22 -0800 (PST) Received: from ?IPv6:2605:a601:a028:986:9914:849d:4b35:e6b9? ([2605:a601:a028:986:9914:849d:4b35:e6b9]) by smtp.gmail.com with ESMTPSA id a71sm34672992ywe.66.2019.01.07.22.57.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 22:57:21 -0800 (PST) From: Bret Jordan Content-Type: multipart/alternative; boundary=Apple-Mail-555F567F-B55A-41FE-8F3B-3F4F01050449 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 7 Jan 2019 23:57:20 -0700 Message-Id: To: cacao@ietf.org X-Mailer: iPhone Mail (16C101) Archived-At: Subject: [Cacao] BoF for Prague X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 06:57:25 -0000 --Apple-Mail-555F567F-B55A-41FE-8F3B-3F4F01050449 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I just wanted to give everyone a heads up that we are still planning on hold= ing a BoF in Prague with the hope of getting a Working Group setup so we can= start running. Bret=20 Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050= --Apple-Mail-555F567F-B55A-41FE-8F3B-3F4F01050449 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit I just wanted to give everyone a heads up that we are still planning on holding a BoF in Prague with the hope of getting a Working Group setup so we can start running.

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
--Apple-Mail-555F567F-B55A-41FE-8F3B-3F4F01050449-- From nobody Tue Jan 8 06:59:08 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02A8126CB6 for ; Tue, 8 Jan 2019 06:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBscJvGK4oMb for ; Tue, 8 Jan 2019 06:59:05 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC09A124BF6 for ; Tue, 8 Jan 2019 06:59:04 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id e12so3717308otl.5 for ; Tue, 08 Jan 2019 06:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aaGew4FZWPuBic6goMC1goGSVV1bXkZI0LXBTkP1nXU=; b=Bp1WpcDh1ylts7aUdOtbejiCFM6/hE1Xw8+D0gr08E2srl5VSN+FH++qnA6Gbd/xdP kNOvBuiJNl5b30xJ73vLQnQUC5yvnLC+nKjOfJn9NuXhI6pJLhxcJnVq10B9scyCZFFE Y0ecZpa+Uct/zj95Az1918SAwNgdx4+PHrcFv6xnGJk/BOaycGJS0BoOjWU3Lypr/jNK u6CTnJob31Jgp0p0862CxZrVaBvkkUhdVzTNzhNNGiVfLbVHpcZwK+Fx1u0vfh479bnC SR54pY4hvi93alNOLtqNVvxu4/2ka2zsY2pT3s+BXDqIeqF3cDPWmWmEXQvB6dEFDe/d ZWlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aaGew4FZWPuBic6goMC1goGSVV1bXkZI0LXBTkP1nXU=; b=YgGnXjN3nZQenJjjA1kgWZLSkfQCWKJTyVin5sfECnXDQ/OaQfxS7Px6adRIHAD126 0z2vo49ojxHZhVvVlwl/RQlcufT2llghfvHg/lz5GqJasBZj6nY6Fr7+6HkkUUbpdI03 94K/VOy4Vey+IY6Vlzp2SQbJWMVGr/MBfSacNwerVUaUgaI+BW75EQfRCRsVZVxR9lD3 kN0/xvmNhz3k/RPGTc1QHlw6FxW6PPenSC0PSQ00KbUTUxLApJvTrGUEJSKZY4jK3nRD yD/dmZ+b4KkF3iB+R6DMeoOebqC3cWHebYjHtehRp+U8TKQJ7/jyhi9a+qOC70VvRCvP aO1Q== X-Gm-Message-State: AJcUukfygxJ5bAw5h2ologGscJ/qRRD9gu25s2T+r/oDP1FfmW7Xy/33 DJjAVd/ON/SDwSfIm07NSfI= X-Google-Smtp-Source: ALg8bN4AvpgH18rD/D3aqGNojQdipBYWMFkWCx1sXCNqaiSIUY9z7wmngrNFxzmTMZeyqXp0x5Gt+g== X-Received: by 2002:a9d:5605:: with SMTP id e5mr1478241oti.226.1546959543995; Tue, 08 Jan 2019 06:59:03 -0800 (PST) Received: from afv.lan (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by smtp.gmail.com with ESMTPSA id i7sm13055934oto.70.2019.01.08.06.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jan 2019 06:59:03 -0800 (PST) From: Adam Montville Message-Id: <26C5F1C6-6FD4-4CF7-B43D-D657CC104BA0@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_87EF7017-9D85-40FF-A9B4-FA7C24B7B58B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 8 Jan 2019 08:59:01 -0600 In-Reply-To: Cc: cacao@ietf.org To: Bret Jordan References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cacao] BoF for Prague X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:59:07 -0000 --Apple-Mail=_87EF7017-9D85-40FF-A9B4-FA7C24B7B58B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for letting us know, Bret. See you there. > On Jan 8, 2019, at 12:57 AM, Bret Jordan = wrote: >=20 > I just wanted to give everyone a heads up that we are still planning = on holding a BoF in Prague with the hope of getting a Working Group = setup so we can start running. >=20 > Bret=20 >=20 > Sent from my Commodore 128D >=20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > --=20 > Cacao mailing list > Cacao@ietf.org > https://www.ietf.org/mailman/listinfo/cacao --Apple-Mail=_87EF7017-9D85-40FF-A9B4-FA7C24B7B58B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks for letting us know, Bret. See you there.

On Jan 8, 2019, at 12:57 AM, Bret Jordan <jordan.ietf@gmail.com> wrote:

I just wanted to give everyone a = heads up that we are still planning on holding a BoF in Prague with the = hope of getting a Working Group setup so we can start running.

Bret 

Sent from = my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D = 1447  F2C0 74F8 ACAE 7415 = 0050
--
Cacao = mailing list
Cacao@ietf.org
https://www.ietf.org/mailman/listinfo/cacao

= --Apple-Mail=_87EF7017-9D85-40FF-A9B4-FA7C24B7B58B-- From nobody Wed Jan 9 01:07:09 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5BD1274D0 for ; Wed, 9 Jan 2019 01:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.364 X-Spam-Level: X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symantec.com header.b=dXBLgEGu; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=symantec.com header.b=Eue6rWca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNm44t-_EUEh for ; Wed, 9 Jan 2019 01:07:05 -0800 (PST) Received: from tussmtoutape02.symantec.com (tussmtoutape02.symantec.com [155.64.38.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E707128CF3 for ; Wed, 9 Jan 2019 01:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=Symantec.com; s=1; c=relaxed/simple; q=dns/txt; i=@Symantec.com; t=1547024824; x=2410938424; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2eOZQMCgqxaE2W613SkcM8fp6E5CNj2ekQd396HJT1s=; b=dXBLgEGum4sdzuaSiPVRPQ/Mb1Pwwp4MQILo6JYbGN/mZkXRGsBfvgwlynM6Ahym G9+G02jyEJtkrOkm4MQ24azzEL49WFjc3nJlgMyG2HCPIa5icjIMbO9nZeuLxJSq QPxac41xLuTdPBSnXHQQkX6n7oPOfdbBAdBEWE5FRPY=; Received: from tussmtmtaapi01.symc.symantec.com (tus3-f5-symc-ext-prd-snat7.net.symantec.com [10.44.130.7]) by tussmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id 13.BB.48042.8B9B53C5; Wed, 9 Jan 2019 09:07:04 +0000 (GMT) X-AuditID: 0a2c7e32-dbbf09e00000bbaa-35-5c35b9b81891 Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat1.net.symantec.com [10.44.130.1]) by tussmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id EB.00.05782.8B9B53C5; Wed, 9 Jan 2019 09:07:04 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 9 Jan 2019 01:07:03 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.128.6) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 9 Jan 2019 01:07:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symantec.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X9MMSj70+5Ycng+S3bp7kaH21zFaA+0ls331lRPFbog=; b=Eue6rWcarClGegDfdyhSk197If65NNmqbNUc76zADvVmXkOlF0VwoLxKzSKu0kZ+4LQzjbxW2Ak9xuwtlcVLX1aG+55Rs/+NzwZZya4r6/+e3JQ6v5XumxLrzSDAsf0Goeg5JT6tUoejunMl26sUfz7YGDRbmSS0JyRo71I1N5I= Received: from MW2PR16MB2361.namprd16.prod.outlook.com (52.132.182.24) by MW2PR16MB2396.namprd16.prod.outlook.com (52.132.182.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.7; Wed, 9 Jan 2019 09:07:01 +0000 Received: from MW2PR16MB2361.namprd16.prod.outlook.com ([fe80::68bd:86a4:db97:4f93]) by MW2PR16MB2361.namprd16.prod.outlook.com ([fe80::68bd:86a4:db97:4f93%2]) with mapi id 15.20.1495.011; Wed, 9 Jan 2019 09:07:01 +0000 From: Erick Thek To: "cacao@ietf.org" Thread-Topic: [Cacao] BoF for Prague Thread-Index: AQHUp/quI2ttw8j380iTYs0iThrgyg== Date: Wed, 9 Jan 2019 09:07:01 +0000 Message-ID: <72FEA6D6-E0DF-443E-8AF1-FD42DE405D2D@symantec.com> References: <26C5F1C6-6FD4-4CF7-B43D-D657CC104BA0@gmail.com> In-Reply-To: <26C5F1C6-6FD4-4CF7-B43D-D657CC104BA0@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [192.92.94.42] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR16MB2396; 6:xe7Ss8RIcmm/k/QH9ebQm+j4BRtySSKa3gk/56P9UVcuAgsu3+qwZhCem+4IwIjB8rdxRXl9br93GXbgmoE7wNd98iyVWSCwzY8Tm5k8JbExc/P7vKs6RTPkWWi8IjrZgpUsBLH5JHTyqwp0ZCOwg6x7WS3wSi8S8YsNAdLxUaqxK3RRkFLK/4XW6YsgQ99lYIenH2FiosUsr3sOc/vzoBVSIq0m2UL+ecqB7VXMyjRqZ1cOKomJDAJl3sdOHCmiRZ5rVLAed2pyY84ehsbjFy6kbopL1qJqme2KLrORAYEufznCAXOCq85eHX4ma6RWRwHTclpxPLIW6QRZTOY2iSMjh22y1ZUR8ncK5AXfibMKUU74Oi18aufVO/K8PDWYprScLpGa0ddmFFV9gztV5s1bkH5e/NSUNZ4IytjCRR0J7qe0dJPK1pu6TvzkeNIKHBAwBMsfphYuqJmZ7tPs1w==; 5:ViLmMefhOJ+Qb0wTaW0xouEOMVbrHPkMgJP4ZuGT8fNB6TntyLTdZz/ORpioqGF7nsMjr+joV9MFtIZtVZShahl+5L9CryqDD511+wBZGuFnVGumC9mR8p1oXH6D10ukjXlPYpG9fGrkOXARsc5cBMvM9OHc5jP9ZRgIP8I0vedz2YaTdbkf+UgK6W5BAW///hRPTXbbJVRBx/Dy0+PD8A==; 7:wB/TvdW5o3w6T2wbeLNmVLPe3VLOlnr8y7p7ixuHYmK13mU5mfoSmIfZXl+3Ga37buXIUXuwP9fiMrLLtYx6jpqc6z2ODKe7/bf8Gr/noFjpy9SvFdbxq809flDZyXoPH0Q+sgqRyt1NiwUIVBxijg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5aab852c-1f42-4255-1acb-08d67611d136 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:MW2PR16MB2396; x-ms-traffictypediagnostic: MW2PR16MB2396: x-microsoft-antispam-prvs: x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(136003)(39860400002)(366004)(396003)(346002)(376002)(199004)(189003)(53936002)(97736004)(80792005)(229853002)(6246003)(2906002)(2501003)(86362001)(68736007)(6436002)(14454004)(5640700003)(6306002)(6512007)(99936001)(54896002)(6486002)(256004)(66066001)(25786009)(236005)(36756003)(82746002)(10290500003)(486006)(6116002)(3846002)(81166006)(81156014)(8676002)(72206003)(966005)(478600001)(1730700003)(99286004)(5660300001)(6916009)(106356001)(6346003)(2616005)(8936002)(476003)(33656002)(58126008)(83716004)(186003)(105586002)(102836004)(76176011)(11346002)(26005)(6506007)(446003)(71200400001)(53546011)(316002)(71190400001)(2351001)(7736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MW2PR16MB2396; H:MW2PR16MB2361.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Erick_Thek@symantec.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: I0QYEljh4gBdLChfmV3oWWnk+cGKDRy9VR9nlvu+Vd9SxVeCQ8PqIF7OjDxTQZBfZ14tD7ARq8O0VIDAaq1XWSTD8G4noCpatodmKqtBOG4vfIxuj4g6gc6yQRvQ3d489c3wlBEVpFDlUKnnf/7lDdRgYlZ63IrLAbZ5xPOKmsGmlqUJr6T1pvH4ngYquM7buHPSwp9MFMbCURyLR74BbiERdFhXws/BqgnQjF15Y5/xWyy7UWWthDZII7rVvIFKQkrjB4YLc6rlj0hWITd2p5Ks4B/VknTzKkfyc0o9RaWCewR0YeT70qOYDDF2neQI spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3629873220_116045368" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5aab852c-1f42-4255-1acb-08d67611d136 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2019 09:07:01.3978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR16MB2396 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHebezs4uNjlPzYSnaNMSl02SCZJoQRFqCQYTYJA/zlKJusotk DTWFzAsp5rrYwijJzPutFKbkpGyEopYW5oeskZTljdGITNrZOUZfXn7v//9c4RFwJQ6eVJCr MVA6DZkvw0WYKKKcHzk0HKuKnn8njbN/aMKT0PGWll+cNJQhOpxN5ecWUbqoxCxRzuTId7xw 7ejFW2YXvwyZE6uRUACEEn732XjVSCSQEJsIBraG8B1j0PKAyxguBN0P/3gMCTGOoH4jlzGW EYzM3eXTH4yo58LsowGccRo48HTDhTGfJQTrzilE5+OEHOYdvR72JfbDzOo1Hs0+RAjcm7Hg jB4KlTOP2RgFVK5Z3CxwtwiFjoZ4GsXEEfi4XMpMpIVa809PFSGRAF2jLzk0IyIQnFfauTRz CX9YcDRzmNV8YWnmNbumH3z9vO3J9XN3qh2eY/VgGLN1YQwHwmxzDaJXAaKcD6MVLrZQJKyb zVyGU6FqcILVFxA8c3lGBve6vRO7GTkPrFY7Wz8A+qsseD2KafpvPIZLwNrZjNEsJrzBfseB MXoy1F2v5TN8AKwLg1yGg6C/4wfLcnj7fvxfjGN1msdwPFRVLyKG90FjzRIbEwsrLzbQfeT1 BAUbjHp9gUFrNJCFVHSMQl9coKYf0n1taoVaW9CHPPdWEjOENntO2hAhQLJd4qnOWJWERxa5 I20o1F3yU0/7NJJiGq2GkvmKwxaVKok4myy+ROm053TGfEpvQ3sFmMxfHMgznJUQF0gDlUdR hZRux+UIhNIyVD1y2qfmjD1M3u46sZWp3KPZdp4PD1tr3OqNaH11KsUYF+8/l+SliZUTNwOs RcntJpkwNa1Cmb7SNn0163bxoiLc1ZkUUpewtpgWc/mNyrRuMZVNdpd+cd4wyb3STfbwDjSW f8gre6otaDWqMLMhNEP/7bnaW9FKNqRMLTQdk2H6HPKgnKvTk38B8NCYwncDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHO7u8ezcVT0vx0RR1GtFKc6AhmBeyK1QY9KGLXYa95FKnbFMy IZcKOjUzaWm20MrKTFdm5oQpqKWJFE4yxC4oLbTyGuYwV7R3Z0RfDr/zf/7PDR6aKzbz/WiF UsOolPJ0CSXiibYUoDBTZ1RyxFwlRA++r6US0N6GhhVOEjom2n6GSVfkMKqtcadFqa+7Zqis +cTz1XqbQIv0caVISAOOhHbDHW4pEtFibEPw+O5vig2IcR+CykUFCUwh6Bq9KWA/PFzJhZH7 zygSqeLA80Ubj3wmESwsvUFsPoWl8M7a6mQvvAEscyV8ltfhELhlMVBED4ViS6PLEw7F8wYH 044WodBcFcOiB46Hial8MlEmlOuXnVWEOBaM3f0clhEOgKVLj7gsc7EPjFvrOGQ1L5i0DFGE veHr5z/OXG9Hp/LOUZceBD29Rh7hABipK0PsKoALBNBdaHMVCoMFvZ5L+ADo2gdc+jiCDptz ZHCs2zrgSeQ0MJsHXfX9oU1noEjNeQoGqr85/WLMQEfNxkoUXvvf2IQvgrmljseyB14Lgzes PKLvgysV5QLCm8E83s4lHAhtzbMulsLbsb5/HuvcMJ9wDOhKPyDCwXCtbNLliYLvLxdRPXJr QkGabLU6Q5OhkcuzFBGycHVuRgr7yB3HlhKekpnxFDnPLRFMqNu+vxdhGkncPSaaI5PFfHmO w9mL1tM8iY9H0tGl42J8Vq5h0hgmi1GdUmWnM+pexKGFflp0crpoOe5q08EdHYX19KGxX/1f DEnmPPEu0+ztPHf7zqHDGsO00K7RhhQN7RFq602WEzWeu1dFy2vmo6UTwS+M9352vZKtxG8z f5xZ8JcdeWj07fmx6cHlQGWzm7Jl2JpgH9Z10zhXoo1D1xsNPrGiqQqx4klI9gVbyTnfT/mr Ep46VS6TclVq+V/5q5F1TwMAAA== X-CFilter-Loop: TUS02 Archived-At: Subject: Re: [Cacao] BoF for Prague X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 09:07:08 -0000 --B_3629873220_116045368 Content-type: multipart/alternative; boundary="B_3629873220_2043572506" --B_3629873220_2043572506 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hey Bret, Very cool. If it happens let me know as Prague is not too far. Erick From: Adam Montville Date: Tuesday, January 8, 2019 at 3:59 PM To: Bret Jordan Cc: Subject: Re: [Cacao] BoF for Prague Thanks for letting us know, Bret. See you there. On Jan 8, 2019, at 12:57 AM, Bret Jordan wrote: I just wanted to give everyone a heads up that we are still planning on holding a BoF in Prague with the hope of getting a Working Group setup so we can start running. Bret Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 -- Cacao mailing list Cacao@ietf.org https://clicktime.symantec.com/35Dw3PsqwnLs9WpnnQX7RxR7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao --B_3629873220_2043572506 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hey Bret,

&n= bsp;

Very cool. If it happens let me know as Pra= gue is not too far.

 

Erick

 

From= : Adam Montville <a= dam.w.montville@gmail.com>
Date: Tuesday, January 8, 2019 at 3:= 59 PM
To: Bret Jordan <jordan.ietf@gmail.com>
Cc: = <cacao@ietf.org>
Subject: Re: [Cacao] BoF for Prague

 

Thanks for letting us know, Bret. See you there.



On Jan 8, 2019, at 12:5= 7 AM, Bret Jordan <jordan.ietf@gma= il.com> wrote:

 

I just wanted to give everyone a heads up= that we are still planning on holding a BoF in Prague with the hope of gett= ing a Working Group setup so we can start running.

 

Bret 

Sent from = my Commodore 128D



<= /p>

PGP Fingerprint: 63B4 FC53 680A 6B7D 1= 447  F2C0 74F8 ACAE 7415 0050

--
Cacao mailing list
Cacao@ietf.org
https://clicktime.symantec.com/35Dw3PsqwnLs9WpnnQX7Rx= R7Vc?u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao



--B_3629873220_2043572506-- --B_3629873220_116045368 Content-type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIJrQYJKoZIhvcNAQcCoIIJnjCCCZoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggcVMIIHETCCBfmgAwIBAgIQEKOfsOrmWmwW5eIcxvaqzzANBgkqhkiG9w0BAQsFADCB sDELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJ IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgGA1UEAxMhU3ltYW50ZWMgQ2xhc3MgMiBF bXBsb3llZSBDQSAtIEczMB4XDTE4MDIwNTAwMDAwMFoXDTE5MDIwNTIzNTk1OVowVjEdMBsG A1UECgwUU3ltYW50ZWMgQ29ycG9yYXRpb24xIDAeBgNVBAsMF1N5bWFudGVjIEVtcGxveWVl IEVtYWlsMRMwEQYDVQQDDApFcmljayBUaGVrMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAqV3NmkacUSXJO5xpkH3gBjZoFu57qLxL3PcG4Jk5QVMloDsiFB6frcW86nhefGav qtN8Wg71py5cQDHi17pJkM2o4NphW+Dv94JiJgELApvYb/LuqsxodUmoQtCYBzHCr1bAHNUv Dfoy/Dpz0dRD1RBLjDCOMBtrC+N4S5njpQ6iMriVuDM0KQf/cq+mp00BQA2tmoQdRKlIKYua kVpgLbMcAzNBVhPxoIuNhnTMxjGeKNWpkCdJ7Hab8oqnf7AmlxzZSA7NDa/OJXwez8MY/gdd 9Ql49e2ujZ0BG86IbnGurKaFuVKz13jjKf+xXpYJc35gKpDwTWsQnn4K/8L4WwIDAQABo4ID fjCCA3owDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwHQYDVR0OBBYEFFaFSmgtcRDwfRFiqt3Vq8LJCLn5MCIGA1UdEQQbMBmBF0VyaWNr X1RoZWtAc3ltYW50ZWMuY29tMB8GA1UdIwQYMBaAFKQzr7DDRoer5XhJsrTiRp/qCfwVMIIB YwYIKwYBBQUHAQEEggFVMIIBUTAnBggrBgEFBQcwAYYbaHR0cDovL3BraS1vY3NwLnN5bWF1 dGguY29tMIIBJAYIKwYBBQUHMAKGggEWbGRhcDovL2RpcmVjdG9yeS5zeW1hdXRoLmNvbS9D TiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIwRW1wbG95ZWUlMjBDQSUyMC0lMjBH MyUyQyUyME9VJTIwJTNEJTIwQ2xhc3MlMjAyJTIwTWFuYWdlZCUyMFBLSSUyMEluZGl2aWR1 YWwlMjBTdWJzY3JpYmVyJTIwQ0ElMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3Ql MjBOZXR3b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBD JTIwJTNEJTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0 cDovL3BraS1jcmwuc3ltYXV0aC5jb20vY2FfMmM3OWQ1ZjBjNDU2ZTBlM2UyZmIzZTIzNjkw M2RhMTUvTGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcCMFIwJgYIKwYB BQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6 Ly93d3cuc3ltYXV0aC5jb20vcnBhMEIGCSqGSIb3DQEJDwQ1MDMwCgYIKoZIhvcNAwcwCwYJ YIZIAWUDBAECMAsGCWCGSAFlAwQBFjALBglghkgBZQMEASowKwYKYIZIAYb4RQEQAwQdMBsG EmCGSAGG+EUBEAECAgEBnaT6dBYFMTY3NDgwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFIUjBj SE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQsFAAOCAQEAj2I+ rS0XKEU494k0ZdJUTsIOjgXIvO88JhQ9Eb6PV107kS+UjMZ0Fs4N0mL9o0bH6qj6wE93tYf4 mLkDH/s+lue1M870kdt6TU1VmSqS8RoLUgfbS7EqV3Uul9iyMPUnSFNXU1yPREjm8gwceDUm K0qZIUi6cWVSzqXNdP8uYVs1g9+oaIGRgsF1THA73LR6KZyGCluBYftCm8uZy3u4JtA08xFB +pbBi0Y3F9BFCRF+kVmJGnxUD1oW6HXGPcE0oXGRXJPJessBLaHW9YQr7iGZy4yLFl9xZe/C JbCxlU915zEsHNnllOz/pOwbEQdRjitg//l+PM/wvLAz9hfYYTGCAlwwggJYAgEBMIHFMIGw MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsT FlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kg SW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMSowKAYDVQQDEyFTeW1hbnRlYyBDbGFzcyAyIEVt cGxveWVlIENBIC0gRzMCEBCjn7Dq5lpsFuXiHMb2qs8wDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQgnaCmv0zSiU6LcEMDNBogG7JoACvT9f4mt5JmhLScvG4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMTA5MDkwNzAwWjANBgkqhkiG 9w0BAQEFAASCAQAbLXkfQXKJHqbPqwxzOvnLcmdN4RxNyLeywLE0LQaxn+KsfESfUr9L3ee9 AXn3nIi7wSL3pmTOGY0cPZbG8/nIqCqCcZ+2wyE2D5I16b4wCOkRoMjmV30PgD9gFA3gI6XO uqPDnoxMURfkmAzomMBe1yvzISSLhCQI87BcUOfZJtS5ndqIblFAv/ufs36+YwFNqaivGGmR nOZB7bYu0R/dxuV8BXLZOUopZOBX3sjY8pJOaLpMUFYBh1qlgAT0+UNfnFgyxJDZhvDUqkPF mmrJr4UtpyMdWe0klvNsjJI7mCdfpg6RonilMxnEUFT6yI1SVwoQ7yqinIq/tYo917SG --B_3629873220_116045368-- From nobody Fri Jan 18 10:27:31 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040581312BE for ; Fri, 18 Jan 2019 10:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3gQ1F5ybSac for ; Fri, 18 Jan 2019 10:27:25 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF19131290 for ; Fri, 18 Jan 2019 10:27:24 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id a20so11868227edc.8 for ; Fri, 18 Jan 2019 10:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=iqTm3Btr9DeQSdTu3HAqg6yTcZlKyl8CxdJ1/oHEUHw=; b=PcMy91cKzVH/pGXmlTQ7MlKzXLcTxp/oGu4XMek3goRXq3sB2pIXmAcDJlZiZ3toQw OJQ+Jx6KYl//zbFXTe7Oq7Z1jbEWnL8IQYezMAGES+MJlXKMfOfiPBnLn0Puw17kou/3 ENn/3IxP07dyVnX4OdKerSjbunANOraT3P4hvism3aXn7g5TIw/+2gV862swOED/XOCC BEjpBL+NzvEbcaPsLgiRRtpG24EDQEnGVzorhh5UbrAmxg5zyy0mMuiKYIYUZoFgBF1w x6bCJl7HYZnAsLCg+OBpCADx8lcJhlkcOwM2QVS1Oo8L54PJWZCNqLa1+NnjyY5h68J8 Ouhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=iqTm3Btr9DeQSdTu3HAqg6yTcZlKyl8CxdJ1/oHEUHw=; b=EUuo+ZcBPvobnJ60y/QFFoLemWitwoe5EHoaSzRmxYMmWBBWJ6wOKtElMZYfuNH5tc tRSRbZc/ev2SkiG/M8VCksLCVAuDfKr2Mx3DkV1T+hlmGBfL1Tx4sJCehkXwdsH3NEMC CQjQ85asKYYuTtdIcUaRAv1SJAit7WgqsV5axBddmKBRbljUaKJK6wSj9t4Cem0+htX4 45kIrYpD2cQ6EgpnxDgHvZvd3x6+SmWg3qiPwW66KeVzbsMhWVZdlUKQbvYVOc7rZT8s ioKkDG3okwFz9yDpRDSZS2sLVbthMcaN48i30QsbttZ85ipBoSF4lq/IEkwkRcMMNM27 Xhqw== X-Gm-Message-State: AJcUukd2quqFjb3AdodW+hDREslwuKP5WVbnXXjCFOEzJ1iaI29GykQx E3Ru0fwK0hj6O8BBtO07aUEfgybn X-Google-Smtp-Source: ALg8bN7ktaDJsq2R3CMgHb98mFiK1c4r4ad987MFNUzzK0DOJA1U0SdOq8XmaV/h9dAobhHUcnVzmQ== X-Received: by 2002:a17:906:4ad7:: with SMTP id u23-v6mr15588132ejt.202.1547836043077; Fri, 18 Jan 2019 10:27:23 -0800 (PST) Received: from [192.168.22.200] ([194.6.185.158]) by smtp.gmail.com with ESMTPSA id p7-v6sm4169622ejx.27.2019.01.18.10.27.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 10:27:22 -0800 (PST) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_77F3FEBE-02EF-40B6-B718-D0CA0E53EF01" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <26B19ECD-0B71-42C3-8AA4-20DD5348E0B5@gmail.com> Date: Fri, 18 Jan 2019 19:27:13 +0100 To: cacao@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cacao] Updated Charter X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 18:27:30 -0000 --Apple-Mail=_77F3FEBE-02EF-40B6-B718-D0CA0E53EF01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, We took in everyone=E2=80=99s comments and feedback and have released a = new charter for this working group. You can find the link to the = charter here: = https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ = The text is also copied below. ##BEGIN # Problem Threat Actors and Intrusion Sets are advancing at an increasing rate = relative to an organization's ability to defend against and respond to = cyber attacks. In addition, it is common that defenders need to manually = identify and process prevention, mitigation, and remediation steps in = order to protect their systems, networks, data, and users. There is also = currently no standard means to easily and dynamically share proposed = prevention, mitigation, or remediation steps and the operational = experience gained from these attacks or their associated successful = responses among a trusted set of organizations.=20 Due to the increasing sophistication and amplitude of cyber attacks the = need for a secure collaborative set of systems providing coordinated = detection and response across hosts, networks, and security = infrastructure has raised significantly. This solution is necessary to = effectively respond to threats in machine relevant time. While some = attacks may be well known to certain security experts and researchers = they are often not documented in a way that would enable automated = prevention, mitigation, or remediation.=20 Key to this coordinated cyber attack response is a coordinated threat = response including a standard information model; a set of functional = capabilities, associated interfaces, and protocols. These key = requirements would be defined in each of the system components across = host; network and security infrastructure to ensure that each system can = work together in a coordinated manner.=20 # Working Group To enable efficient collaboration and facilitate the rapid sharing of = preventative, mitigative, and remediative actions this working group = will focus on defining the set of technologies (protocols, interfaces, = functional capabilities, and information model) required to detect, = prevent, mitigate, and remediate threats. This solution will also define = the machine-readable actions to enable an action-oriented defensive = system. This effort will focus on providing the functionality = requirements for each system that would participate in a coordinated = threat response; the interfaces they should support including the = transport mechanism used and finally the information model across those = systems to enable the coordinated actions in a structured secure manner. Each collaborative course of action will consist of a sequence of cyber = defense actions that can be executed by the various systems that those = actions target. Further, these COAs can be coordinated and deployed = across heterogeneous cyber security systems such that both the actions = requested and the resultant outcomes may be monitored and verified. = These actions will be referenceable in a connected data structure that = provides support for connected data object and efficient operational use = of those data objects such as Threat Actors, Campaigns, Intrusion Sets, = Malware, Attack Patterns, and other adversarial techniques, tactics, and = procedures (TTPs).=20 Where possible the working group will leverage existing efforts that = *may* define the atomic actions to be included in a process or sequence. = The working group will not consider how shared actions are = used/enforced, except where a response is expected for such a received = shared action by a receiving party. It will also focus on the = requirements for the correct construction and correct distribution of = the structured actions and their corresponding interfaces and protocols. # Goals This working group has the following major goals: =E2=80=A2 Document the use cases and requirements =E2=80=A2 Identify and document the system functions and roles = that must exist with associated protocols for a coordinated threat = response system to operate effectively =E2=80=A2 Identify and document the configuration for a series = of protocols that can be used to distribute courses of action in both = direct delivery and publish-subscribe methods =E2=80=A2 Identify and document the mechanism(s) required to = monitor, report and alert on effective distribution of CACAO actions and = the potential threat response to those actions =E2=80=A2 Create an information and data model that can capture = and enable collaborative courses of action (sometimes called playbooks) = that will be used in the coordinated threat response systems=20 =E2=80=A2 Define and create a series of tests and documents to = assist with interoperability of the various systems involved in the = coordinated threat response system. =20 # Deliverables=20 The working group plans to create informational and standards track = documents, some of which may be published through the IETF RFC stream. =E2=80=A2 CACAO Use Cases and Requirements =E2=80=A2 CACAO Functional Architecture: Roles and Interfaces =E2=80=A2 CACAO Interface Specification =E2=80=A2 CACAO JSON Data Model =E2=80=A2 CACAO Distribution and Response Application Layer = Protocol The working group may decide to not publish the use cases and = requirements as RFCs. That decision will be made during the lifetime of = the working group.=20 ##END Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." --Apple-Mail=_77F3FEBE-02EF-40B6-B718-D0CA0E53EF01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

We = took in everyone=E2=80=99s comments and feedback and have released a new = charter for this working group.  You can find the link to the = charter here: https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/



# Problem
Threat Actors and Intrusion Sets are = advancing at an increasing rate relative to an organization's ability to = defend against and respond to cyber attacks. In addition, it is common = that defenders need to manually identify and process prevention, = mitigation, and remediation steps in order to protect their systems, = networks, data, and users. There is also currently no standard means to = easily and dynamically share proposed prevention, mitigation, or = remediation steps and the operational experience gained from these = attacks or their associated successful responses among a trusted set of = organizations. 

Due to the increasing = sophistication and amplitude of cyber attacks the need for a secure = collaborative set of systems providing coordinated detection and = response across hosts, networks, and security infrastructure has raised = significantly. This solution is necessary to effectively respond to = threats in machine relevant time. While some attacks may be well known = to certain security experts and researchers they are often not = documented in a way that would enable automated prevention, mitigation, = or remediation. 

Key to this = coordinated cyber attack response is a coordinated threat response = including a standard information model; a set of functional = capabilities, associated interfaces, and protocols. These key = requirements would be defined in each of the system components across = host; network and security infrastructure to ensure that each system can = work together in a coordinated manner. 

# Working Group
To enable efficient = collaboration and facilitate the rapid sharing of preventative, = mitigative, and remediative actions this working group will focus on = defining the set of technologies (protocols, interfaces, functional = capabilities, and information model) required to detect, prevent, = mitigate, and remediate threats. This solution will also define the = machine-readable actions to enable an action-oriented defensive system. = This effort will focus on providing the functionality requirements for = each system that would participate in a coordinated threat response; the = interfaces they should support including the transport mechanism used = and finally the information model across those systems to enable the = coordinated actions in a structured secure manner.

Each collaborative course of action will consist of a = sequence of cyber defense actions that can be executed by the various = systems that those actions target. Further, these COAs can be = coordinated and deployed across heterogeneous cyber security systems = such that both the actions requested and the resultant outcomes may be = monitored and verified. These actions will be referenceable in a = connected data structure that provides support for connected data object = and efficient operational use of those data objects such as Threat = Actors, Campaigns, Intrusion Sets, Malware, Attack Patterns, and other = adversarial techniques, tactics, and procedures (TTPs). 

Where possible the working group will leverage = existing efforts that *may* define the atomic actions to be included in = a process or sequence. The working group will not consider how shared = actions are used/enforced, except where a response is expected for such = a received shared action by a receiving party. It will also focus on the = requirements for the correct construction and correct distribution of = the structured actions and their corresponding interfaces and = protocols.

# Goals
This = working group has the following major goals:
= =E2=80=A2 Document the use cases and requirements
=E2=80=A2 Identify and document = the system functions and roles that must exist with associated protocols = for a coordinated threat response system to operate effectively
=E2=80=A2 Identify and document = the configuration for a series of protocols that can be used to = distribute courses of action in both direct delivery and = publish-subscribe methods
=E2=80=A2 = Identify and document the mechanism(s) required to monitor, report and = alert on effective distribution of CACAO actions and the potential = threat response to those actions
=E2=80=A2 = Create an information and data model that can capture and enable = collaborative courses of action (sometimes called playbooks) that will = be used in the coordinated threat response systems 
=E2=80=A2 Define and create a = series of tests and documents to assist with interoperability of the = various systems involved in the coordinated threat response system.
 
# Deliverables 
The working group plans to create informational and standards = track documents, some of which may be published through the IETF RFC = stream.
=E2=80=A2 CACAO Use Cases and = Requirements
=E2=80=A2 = CACAO Functional Architecture: Roles and Interfaces
=E2=80=A2 CACAO Interface = Specification
=E2=80=A2 = CACAO JSON Data Model
=E2=80=A2 = CACAO Distribution and Response Application Layer Protocol

The working group may decide to not = publish the use cases and requirements as RFCs. That decision will be = made during the lifetime of the working group. 




Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

= --Apple-Mail=_77F3FEBE-02EF-40B6-B718-D0CA0E53EF01-- From nobody Fri Jan 18 10:29:12 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311C31312C0 for ; Fri, 18 Jan 2019 10:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5gY9Gg3e9uy for ; Fri, 18 Jan 2019 10:29:04 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28964131290 for ; Fri, 18 Jan 2019 10:29:04 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id f9so11863492eds.10 for ; Fri, 18 Jan 2019 10:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=SFOePQm2IPgb9hQJQBTRQjGeKpSnO4JXVvLi8Rc529E=; b=WhlKgtEoJrSVrFQLWVPealCzDXA86Ckx+pFJXxLZrR9yLxrpyUZcNzdhy7k6JWtipy tfT81BI+5GB8IXACCJREvWVPCiOLhQ50aIGixOsh9a78iMkbs+3lz8v01sPDnX3XSOoF OkFboc/G54IXrdtTgu9aUrXHeqD6zQHcZqQsU8PW+5fQ0T1VxMgspxgd/7VPeLLOYHz0 14OV2p0qZDGvTk6sFqsAbb4KNjsem+mPapmyYWxTCBU1Ma9qZaMYHVAvFDQX/IJ/FCAC JUeS48mKzEvA3uaoPacxqWUnBkd/BxNgRM1FBnP6IgurbEvO3gTuNIiBhUo7aYfS5qMP ts6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=SFOePQm2IPgb9hQJQBTRQjGeKpSnO4JXVvLi8Rc529E=; b=V2Vvdg7NSoMRL/bHPnmNSYgUoTu/YCga3ZIVBV0ja0lhZZWQszNdnn4H4zQwiOzJTF qYNwaOqtZasosuTOYhXs9ucZKjTsjqI4g8io3RdLQtQ1xqK3XnkCx4QUIP4Mjd02zfHs MTGRtY/JrbsMMrz73UBVSdChpXWKCrPIJplbmeeDH/uNC07DvBa28GqzntR6GSbssH57 RA9cdXZW2fSIszsvQQlp+cdG2KZhPln2W58lfM65ivbb94QpufLTZ7c6/D1HGEo4v4p6 vSIevnRBsOILLQOP1GzsXTFrr7tpnQj19EaLjczIWf5l0yGDn9E8o6DCA+TWGNroM+0Z J87g== X-Gm-Message-State: AJcUukcP/pajdkWKFVvymT3ghS3bHGAadL/MopDeeQEez7us6mgSaU8x 4JACPAoeil2LV1cOrppPyez1nkXM X-Google-Smtp-Source: ALg8bN7XJQ5bY5n62dGH1VQ4dbj/vGfTEW/J9Nd12hSHi1YEwIua4QmwhBQ8VtaC/DdkJZKhZW1pmQ== X-Received: by 2002:a50:d311:: with SMTP id g17mr16552041edh.187.1547836141987; Fri, 18 Jan 2019 10:29:01 -0800 (PST) Received: from [192.168.22.200] ([194.6.185.158]) by smtp.gmail.com with ESMTPSA id n23-v6sm3884794ejx.57.2019.01.18.10.29.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 10:29:01 -0800 (PST) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_2EDCC4C0-A8C0-4EEB-BC71-06545A49C854" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 18 Jan 2019 19:28:53 +0100 References: <26B19ECD-0B71-42C3-8AA4-20DD5348E0B5@gmail.com> To: cacao@ietf.org In-Reply-To: <26B19ECD-0B71-42C3-8AA4-20DD5348E0B5@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cacao] Updated Charter X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 18:29:08 -0000 --Apple-Mail=_2EDCC4C0-A8C0-4EEB-BC71-06545A49C854 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Also, if there are additional comments or suggestions, please feel free = to make them in suggestion mode in the master google doc.=20 = https://docs.google.com/document/d/1Kh7HEWeqj4-zWuPNDflDkKNJUaqZAOmUl9pBJB= Rjvv8/edit# = Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jan 18, 2019, at 7:27 PM, Bret Jordan = wrote: >=20 > All, >=20 > We took in everyone=E2=80=99s comments and feedback and have released = a new charter for this working group. You can find the link to the = charter here: = https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ = >=20 > The text is also copied below. >=20 > ##BEGIN >=20 > # Problem > Threat Actors and Intrusion Sets are advancing at an increasing rate = relative to an organization's ability to defend against and respond to = cyber attacks. In addition, it is common that defenders need to manually = identify and process prevention, mitigation, and remediation steps in = order to protect their systems, networks, data, and users. There is also = currently no standard means to easily and dynamically share proposed = prevention, mitigation, or remediation steps and the operational = experience gained from these attacks or their associated successful = responses among a trusted set of organizations.=20 >=20 > Due to the increasing sophistication and amplitude of cyber attacks = the need for a secure collaborative set of systems providing coordinated = detection and response across hosts, networks, and security = infrastructure has raised significantly. This solution is necessary to = effectively respond to threats in machine relevant time. While some = attacks may be well known to certain security experts and researchers = they are often not documented in a way that would enable automated = prevention, mitigation, or remediation.=20 >=20 > Key to this coordinated cyber attack response is a coordinated threat = response including a standard information model; a set of functional = capabilities, associated interfaces, and protocols. These key = requirements would be defined in each of the system components across = host; network and security infrastructure to ensure that each system can = work together in a coordinated manner.=20 >=20 > # Working Group > To enable efficient collaboration and facilitate the rapid sharing of = preventative, mitigative, and remediative actions this working group = will focus on defining the set of technologies (protocols, interfaces, = functional capabilities, and information model) required to detect, = prevent, mitigate, and remediate threats. This solution will also define = the machine-readable actions to enable an action-oriented defensive = system. This effort will focus on providing the functionality = requirements for each system that would participate in a coordinated = threat response; the interfaces they should support including the = transport mechanism used and finally the information model across those = systems to enable the coordinated actions in a structured secure manner. >=20 > Each collaborative course of action will consist of a sequence of = cyber defense actions that can be executed by the various systems that = those actions target. Further, these COAs can be coordinated and = deployed across heterogeneous cyber security systems such that both the = actions requested and the resultant outcomes may be monitored and = verified. These actions will be referenceable in a connected data = structure that provides support for connected data object and efficient = operational use of those data objects such as Threat Actors, Campaigns, = Intrusion Sets, Malware, Attack Patterns, and other adversarial = techniques, tactics, and procedures (TTPs).=20 >=20 > Where possible the working group will leverage existing efforts that = *may* define the atomic actions to be included in a process or sequence. = The working group will not consider how shared actions are = used/enforced, except where a response is expected for such a received = shared action by a receiving party. It will also focus on the = requirements for the correct construction and correct distribution of = the structured actions and their corresponding interfaces and protocols. >=20 > # Goals > This working group has the following major goals: > =E2=80=A2 Document the use cases and requirements > =E2=80=A2 Identify and document the system functions and roles = that must exist with associated protocols for a coordinated threat = response system to operate effectively > =E2=80=A2 Identify and document the configuration for a series = of protocols that can be used to distribute courses of action in both = direct delivery and publish-subscribe methods > =E2=80=A2 Identify and document the mechanism(s) required to = monitor, report and alert on effective distribution of CACAO actions and = the potential threat response to those actions > =E2=80=A2 Create an information and data model that can capture = and enable collaborative courses of action (sometimes called playbooks) = that will be used in the coordinated threat response systems=20 > =E2=80=A2 Define and create a series of tests and documents to = assist with interoperability of the various systems involved in the = coordinated threat response system. > =20 > # Deliverables=20 > The working group plans to create informational and standards track = documents, some of which may be published through the IETF RFC stream. > =E2=80=A2 CACAO Use Cases and Requirements > =E2=80=A2 CACAO Functional Architecture: Roles and Interfaces > =E2=80=A2 CACAO Interface Specification > =E2=80=A2 CACAO JSON Data Model > =E2=80=A2 CACAO Distribution and Response Application Layer = Protocol >=20 > The working group may decide to not publish the use cases and = requirements as RFCs. That decision will be made during the lifetime of = the working group.=20 >=20 >=20 >=20 > ##END >=20 > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing = that can not be unscrambled is an egg." >=20 --Apple-Mail=_2EDCC4C0-A8C0-4EEB-BC71-06545A49C854 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Also,= if there are additional comments or suggestions, please feel free to = make them in suggestion mode in the master google doc. 




Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

On Jan 18, 2019, at 7:27 PM, Bret Jordan <jordan.ietf@gmail.com> wrote:

All,

We took in everyone=E2=80=99s comments = and feedback and have released a new charter for this working group. =  You can find the link to the charter here: https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/



# Problem
Threat Actors and Intrusion Sets are = advancing at an increasing rate relative to an organization's ability to = defend against and respond to cyber attacks. In addition, it is common = that defenders need to manually identify and process prevention, = mitigation, and remediation steps in order to protect their systems, = networks, data, and users. There is also currently no standard means to = easily and dynamically share proposed prevention, mitigation, or = remediation steps and the operational experience gained from these = attacks or their associated successful responses among a trusted set of = organizations. 

Due to the increasing = sophistication and amplitude of cyber attacks the need for a secure = collaborative set of systems providing coordinated detection and = response across hosts, networks, and security infrastructure has raised = significantly. This solution is necessary to effectively respond to = threats in machine relevant time. While some attacks may be well known = to certain security experts and researchers they are often not = documented in a way that would enable automated prevention, mitigation, = or remediation. 

Key to this = coordinated cyber attack response is a coordinated threat response = including a standard information model; a set of functional = capabilities, associated interfaces, and protocols. These key = requirements would be defined in each of the system components across = host; network and security infrastructure to ensure that each system can = work together in a coordinated manner. 

# Working Group
To enable efficient = collaboration and facilitate the rapid sharing of preventative, = mitigative, and remediative actions this working group will focus on = defining the set of technologies (protocols, interfaces, functional = capabilities, and information model) required to detect, prevent, = mitigate, and remediate threats. This solution will also define the = machine-readable actions to enable an action-oriented defensive system. = This effort will focus on providing the functionality requirements for = each system that would participate in a coordinated threat response; the = interfaces they should support including the transport mechanism used = and finally the information model across those systems to enable the = coordinated actions in a structured secure manner.

Each collaborative course of action will consist of a = sequence of cyber defense actions that can be executed by the various = systems that those actions target. Further, these COAs can be = coordinated and deployed across heterogeneous cyber security systems = such that both the actions requested and the resultant outcomes may be = monitored and verified. These actions will be referenceable in a = connected data structure that provides support for connected data object = and efficient operational use of those data objects such as Threat = Actors, Campaigns, Intrusion Sets, Malware, Attack Patterns, and other = adversarial techniques, tactics, and procedures (TTPs). 

Where possible the working group will leverage = existing efforts that *may* define the atomic actions to be included in = a process or sequence. The working group will not consider how shared = actions are used/enforced, except where a response is expected for such = a received shared action by a receiving party. It will also focus on the = requirements for the correct construction and correct distribution of = the structured actions and their corresponding interfaces and = protocols.

# Goals
This = working group has the following major goals:
= =E2=80=A2 Document the use cases and requirements
=E2=80=A2 Identify and document = the system functions and roles that must exist with associated protocols = for a coordinated threat response system to operate effectively
=E2=80=A2 Identify and document = the configuration for a series of protocols that can be used to = distribute courses of action in both direct delivery and = publish-subscribe methods
=E2=80=A2 = Identify and document the mechanism(s) required to monitor, report and = alert on effective distribution of CACAO actions and the potential = threat response to those actions
=E2=80=A2 = Create an information and data model that can capture and enable = collaborative courses of action (sometimes called playbooks) that will = be used in the coordinated threat response systems 
=E2=80=A2 Define and create a = series of tests and documents to assist with interoperability of the = various systems involved in the coordinated threat response system.
 
# Deliverables 
The working group plans to create informational and standards = track documents, some of which may be published through the IETF RFC = stream.
=E2=80=A2 CACAO Use Cases and = Requirements
=E2=80=A2 = CACAO Functional Architecture: Roles and Interfaces
=E2=80=A2 CACAO Interface = Specification
=E2=80=A2 = CACAO JSON Data Model
=E2=80=A2 = CACAO Distribution and Response Application Layer Protocol

The working group may decide to not = publish the use cases and requirements as RFCs. That decision will be = made during the lifetime of the working group. 




= --Apple-Mail=_2EDCC4C0-A8C0-4EEB-BC71-06545A49C854-- From nobody Fri Jan 25 20:51:18 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2FB13116F for ; Fri, 25 Jan 2019 20:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4Ch7GZLx_2D for ; Fri, 25 Jan 2019 20:51:13 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96405131171 for ; Fri, 25 Jan 2019 20:51:13 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0Q4pAmL007042 for ; Fri, 25 Jan 2019 23:51:10 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x0Q4pAmL007042 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1548478270; bh=ddsFiRXTBYVYaZf9bFp8yUZmdLmc1g07O1GN1db95VA=; h=From:To:Subject:Date:From; b=o+skSrpT3I+8qse15DDnbU1nu1dCp2TIbGpdxt0/1qRPTE8XvVfnwgqrG7yQI71L7 NxbateXZjvZ6/WHJ/VgP2DS9t6Bk7MJpTbw0ixMAkysUoOAPBPyMVpkmBYTPn3Jkh7 z8+NzR3F81OPE8YSWQCzi13rxrZNym+Fc01fc6TQ= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0Q4p4E7011445 for ; Fri, 25 Jan 2019 23:51:05 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Fri, 25 Jan 2019 23:51:04 -0500 From: Roman Danyliw To: "cacao@ietf.org" Thread-Topic: Charter Feedback Thread-Index: AdS1MW6caKSa6DR7RXaqaTLnUibClA== Date: Sat, 26 Jan 2019 04:51:04 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC018579A01D@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cacao] Charter Feedback X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2019 04:51:17 -0000 Hello! I've reviewed the latest (01/18/2019) charter language per https://mailarch= ive.ietf.org/arch/msg/cacao/FErdmnk2MhOqG7kkDk2oBIthbqQ. As is, I have a f= ew concerns. =20 In broad strokes:=20 ** The notional output of the WG isn't clear ** There are no references to related work in the IETF (e.g., MILE, I2NSF) = or in the community See inline comments of the charter text for additional comments. > # Problem > Threat Actors and Intrusion Sets are advancing at an increasing rate > relative to an organization's ability to defend against and respond to cy= ber > attacks.=20 Editorial: "advancing" how? I'm stumbling with this opening sentence. > In addition, it is common that defenders need to manually identify > and process prevention, mitigation, and remediation steps in order to > protect their systems, networks, data, and users.=20 I agree with this text in that manual identification of what to do in respo= nse to an attack is prevalent. However, I push back on the "need" to manua= lly process prevention, mitigation and remediation steps -- there is a lot = of options for IT automation/SecOps (ansible, puppet, etc.) once the action= is encoded. > There is also currently no > standard means to easily and dynamically share proposed prevention, > mitigation, or remediation steps and the operational experience gained > from these attacks or their associated successful responses among a trust= ed > set of organizations. Concur. It's the lack of a standardized approach to share these COAs acros= s organizations and interoperability across tech stacks which strikes me as= a/the key issue. > > > > Due to the increasing sophistication and amplitude of cyber attacks the > need for a secure collaborative set of systems providing coordinated > detection and response across hosts, networks, and security infrastructur= e > has raised significantly. This solution is necessary to effectively respo= nd to > threats in machine relevant time. While some attacks may be well known to > certain security experts and researchers they are often not documented in= a > way that would enable automated prevention, mitigation, or remediation. > > > > Key to this coordinated cyber attack response is a coordinated threat > response including a standard information model; a set of functional > capabilities, associated interfaces, and protocols. These key requirement= s > would be defined in each of the system components across host; network > and security infrastructure to ensure that each system can work together = in a > coordinated manner. For me, these two paragraphs didn't add anything describing the problem. T= hey read more as a solution to the first paragraph which seems more appropr= iate in later parts of the charter text. > > # Working Group > > To enable efficient collaboration and facilitate the rapid sharing of > preventative, mitigative, and remediative actions this working group will > focus on defining the set of technologies (protocols, interfaces, functio= nal > capabilities, and information model) required to detect, prevent, mitigat= e, > and remediate threats.=20 IMO, the statement "[T]his working group will focus on defining the set of = technologies to detect, prevent, mitigate and remediate threat" seems too b= road. This WG seems to be proposing a particular solution, automated COA e= xchange. Furthermore, I see no deliverables related to threat detection. Editorial: The sentence states "prevent, mitigate and remediate" twice. =20 Editorial: I recommend the first sentence of this section to be a declarati= ve statement of what this WG would do. The simpler language used in the sl= ide #2 of the 10/24/2018 Intro Webex, https://mailarchive.ietf.org/arch/msg= /cacao/-cgdaJG6uM71IeNwp3oxl6rRQiE, is to the point. > This solution will also define the machine-readable > actions to enable an action-oriented defensive system. This effort will f= ocus > on providing the functionality requirements for each system that would > participate in a coordinated threat response; the interfaces they should > support including the transport mechanism used and finally the informatio= n > model across those systems to enable the coordinated actions in a > structured secure manner. This is the third time in the text where the list of functional requirement= s, interfaces, and info model is enumerated as a need. The first time was = in the Problem section, the second was parenthetically in the previous para= graph, and it will again be discussed in the Goals and Deliverables. I don= 't think this paragraph is needed. =20 > > Each collaborative course of action will consist of a sequence of cyber > defense actions that can be executed by the various systems that those > actions target. Further, these COAs can be coordinated and deployed acros= s > heterogeneous cyber security systems such that both the actions requested > and the resultant outcomes may be monitored and verified. These actions > will be referenceable in a connected data structure that provides support= for > connected data object and efficient operational use of those data objects > such as Threat Actors, Campaigns, Intrusion Sets, Malware, Attack Pattern= s, > and other adversarial techniques, tactics, and procedures (TTPs). What are "data objects"? I recommend merely describing the class of data t= hat needs to be exchanged in the COA; and with whom and avoid further speci= ficity that would require additional definitions.=20 Why are "Threat Actors, Campaigns ..." capitalized like proper nouns in thi= s context (I appreciate that these are STIX objects). > > Where possible the working group will leverage existing efforts that *m= ay* > define the atomic actions to be included in a process or sequence.=20 I recommend you specify these related efforts. > The > working group will not consider how shared actions are used/enforced, > except where a response is expected for such a received shared action by = a > receiving party. It will also focus on the requirements for the correct > construction and correct distribution of the structured actions and their > corresponding interfaces and protocols. Is "requirements for the correct construction and ..." the same thing as sp= ecifying a MTI protocol or data model? > > # Goals > > This working group has the following major goals: > > * Document the use cases and requirements > > * Identify and document the system functions and roles that must > exist with associated protocols for a coordinated threat response system = to > operate effectively I initially read this as an informational architecture draft per the delive= rable list. However, the language "must exist" suggests something stronger= . Is this the architecture draft? Are the "associated protocols" different than the ones that would be specif= ied by this WG? What is the dependency between the "roles"/"system functions" documentation= and the data model and protocol work? > > * Identify and document the configuration for a series of protocols > that can be used to distribute courses of action in both direct delivery = and > publish-subscribe methods "Identify and document" reads to me like a new protocol won't be specified.= However, the deliverable list states that there will be a "CACAO Distribu= tion and Response Application Layer Protocol". Could you please clarity. = If you intend to make a standard track document with a protocol, I recommen= d you use the verb "specify"/"standardize" > > * Identify and document the mechanism(s) required to monitor, > report and alert on effective distribution of CACAO actions and the poten= tial > threat response to those actions To which deliverable does this map? What are "mechanisms"? > > * Create an information and data model that can capture and > enable collaborative courses of action (sometimes called playbooks) that > will be used in the coordinated threat response systems This text references information and data models, the deliverables only men= tion a data model. Is the information model going to be specified in the J= SON draft? > > * Define and create a series of tests and documents to assist with > interoperability of the various systems involved in the coordinated threa= t > response system. This bullet doesn't appear to have a corresponding item in the deliverable = section. Furthermore, per the language "series of tests and documents" how= will the "tests" manifest if not in a document? If it's not in a draft, i= t is not a WG work item. > > # Deliverables > > The working group plans to create informational and standards track > documents, some of which may be published through the IETF RFC stream. > > * CACAO Use Cases and Requirements > > * CACAO Functional Architecture: Roles and Interfaces > > * CACAO Interface Specification > > * CACAO JSON Data Model draft-jordan-cacao-introduction made reference to a CBOR data model. Is th= at still in scope? > > * CACAO Distribution and Response Application Layer Protocol > > IMO, it would be clearer to collapse the current list of goals with the del= iverables. =20 Roman From nobody Sat Jan 26 09:36:05 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE5130F26 for ; Sat, 26 Jan 2019 09:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k53T5CGg6F3b for ; Sat, 26 Jan 2019 09:35:58 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863F3130F15 for ; Sat, 26 Jan 2019 09:35:58 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id x6so10230949ioa.9 for ; Sat, 26 Jan 2019 09:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MvZv/97ExLYfewI97FVAJRcwsUDmFD6LhtOxlvgMCcA=; b=l8L15LzRq4o1JfF53TMOFCXwiE6wRyr3D8XxHvhS4BlXdNv+ZunuwQp5s+YTiTQW12 4b4jvyk5IMKE91s8QUyys4BbKqoBiL5pPmYGZc+kSx0AtGY7e+o4VGtVvUjijtFnN7YQ Y3zpm6567TzRCS+RmriG2tJugNOXwQsHKlmyZ+sk09MJPxwpA4jsZUhFFZr/HR5jEznr LcVT+X1bYYT6GY62VWyfYjz7AGdIloGs6/XJiE4NA0J7xc/nC2B8Y1VM7Ys5wV/MuAOM tDnZUI+UozUrdHs90REnIfvKkvvpr+NQjWeQDhPvxYOXceQ6gxJ6zKcKkCjWaZW1EB66 crEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MvZv/97ExLYfewI97FVAJRcwsUDmFD6LhtOxlvgMCcA=; b=NdRf1TLlaeeATCzxmt9mshGz188tavftcGgtGlMezML9LmNCqBFmZ8n871DsBsuDWu ct6NoSZ0mkjKc5iVCKeS1a67Q1qxHdpqRVjoEQD0OJ3aTjtbUZVBwOwXJjaurZ5OoZgq bH0e0AE7a3c9uHeNrwQvlu//1Ue4eOWb672+ZXPl1TAw3x2x+xK/9W7o7Og2T31PUggw rwBm9rqTRfyP/N+ZMzZDT8XX78ejL5So6MdiyHEtjpSQUadgMfJCDqS0SpAexcDmI/Xe THh2buqSo+o65WmomE+luO3dft7oxMoeYO1Yqqisi8ZGUG+IBXW4vdQXab4fBN0Zs9JK wmvQ== X-Gm-Message-State: AHQUAuY9a6GfAd9Q45UQ+uKRbGdNFJKelbp6Nc8nj9xxKWmOlTxiTViu iXSjq86Y0tzf694aqie9SQgv3uDH X-Google-Smtp-Source: AHgI3Iae2PX8uQiG/1LtMMn2lwqr0YatKvLmBdqg9G44glqyoZ0pDX+wcFnYhyzHs+i4T4bwDxkvnw== X-Received: by 2002:a6b:e401:: with SMTP id u1mr9219093iog.284.1548524157243; Sat, 26 Jan 2019 09:35:57 -0800 (PST) Received: from ?IPv6:2605:a601:a028:986:8857:628b:e422:abf8? ([2605:a601:a028:986:8857:628b:e422:abf8]) by smtp.gmail.com with ESMTPSA id i135sm14407704iti.34.2019.01.26.09.35.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jan 2019 09:35:56 -0800 (PST) From: Bret Jordan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1EEA6D1C-022B-489F-8F70-CEB241A529BB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 26 Jan 2019 10:35:39 -0700 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC018579A01D@marathon> Cc: "cacao@ietf.org" To: Roman Danyliw References: <359EC4B99E040048A7131E0F4E113AFC018579A01D@marathon> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cacao] Charter Feedback X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2019 17:36:04 -0000 --Apple-Mail=_1EEA6D1C-022B-489F-8F70-CEB241A529BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Roman, Thank you for the very careful and thoughtful response. We will work on = this and try and produce an updated version in the coming days. Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." > On Jan 25, 2019, at 9:51 PM, Roman Danyliw wrote: >=20 > Hello! >=20 > I've reviewed the latest (01/18/2019) charter language per = https://mailarchive.ietf.org/arch/msg/cacao/FErdmnk2MhOqG7kkDk2oBIthbqQ. = As is, I have a few concerns. >=20 > In broad strokes:=20 > ** The notional output of the WG isn't clear > ** There are no references to related work in the IETF (e.g., MILE, = I2NSF) or in the community >=20 > See inline comments of the charter text for additional comments. >=20 >> # Problem >> Threat Actors and Intrusion Sets are advancing at an increasing rate >> relative to an organization's ability to defend against and respond = to cyber >> attacks.=20 >=20 > Editorial: "advancing" how? I'm stumbling with this opening sentence. >=20 >> In addition, it is common that defenders need to manually identify >> and process prevention, mitigation, and remediation steps in order to >> protect their systems, networks, data, and users.=20 >=20 > I agree with this text in that manual identification of what to do in = response to an attack is prevalent. However, I push back on the "need" = to manually process prevention, mitigation and remediation steps -- = there is a lot of options for IT automation/SecOps (ansible, puppet, = etc.) once the action is encoded. >=20 >> There is also currently no >> standard means to easily and dynamically share proposed prevention, >> mitigation, or remediation steps and the operational experience = gained >> from these attacks or their associated successful responses among a = trusted >> set of organizations. >=20 > Concur. It's the lack of a standardized approach to share these COAs = across organizations and interoperability across tech stacks which = strikes me as a/the key issue. >=20 >>>=20 >>> Due to the increasing sophistication and amplitude of cyber attacks = the >> need for a secure collaborative set of systems providing coordinated >> detection and response across hosts, networks, and security = infrastructure >> has raised significantly. This solution is necessary to effectively = respond to >> threats in machine relevant time. While some attacks may be well = known to >> certain security experts and researchers they are often not = documented in a >> way that would enable automated prevention, mitigation, or = remediation. >>>=20 >>> Key to this coordinated cyber attack response is a coordinated = threat >> response including a standard information model; a set of functional >> capabilities, associated interfaces, and protocols. These key = requirements >> would be defined in each of the system components across host; = network >> and security infrastructure to ensure that each system can work = together in a >> coordinated manner. >=20 > For me, these two paragraphs didn't add anything describing the = problem. They read more as a solution to the first paragraph which = seems more appropriate in later parts of the charter text. >=20 >>> # Working Group >>> To enable efficient collaboration and facilitate the rapid sharing = of >> preventative, mitigative, and remediative actions this working group = will >> focus on defining the set of technologies (protocols, interfaces, = functional >> capabilities, and information model) required to detect, prevent, = mitigate, >> and remediate threats.=20 >=20 > IMO, the statement "[T]his working group will focus on defining the = set of technologies to detect, prevent, mitigate and remediate threat" = seems too broad. This WG seems to be proposing a particular solution, = automated COA exchange. Furthermore, I see no deliverables related to = threat detection. >=20 > Editorial: The sentence states "prevent, mitigate and remediate" = twice. =20 >=20 > Editorial: I recommend the first sentence of this section to be a = declarative statement of what this WG would do. The simpler language = used in the slide #2 of the 10/24/2018 Intro Webex, = https://mailarchive.ietf.org/arch/msg/cacao/-cgdaJG6uM71IeNwp3oxl6rRQiE, = is to the point. >=20 >> This solution will also define the machine-readable >> actions to enable an action-oriented defensive system. This effort = will focus >> on providing the functionality requirements for each system that = would >> participate in a coordinated threat response; the interfaces they = should >> support including the transport mechanism used and finally the = information >> model across those systems to enable the coordinated actions in a >> structured secure manner. >=20 > This is the third time in the text where the list of functional = requirements, interfaces, and info model is enumerated as a need. The = first time was in the Problem section, the second was parenthetically in = the previous paragraph, and it will again be discussed in the Goals and = Deliverables. I don't think this paragraph is needed. =20 >=20 >>> Each collaborative course of action will consist of a sequence of = cyber >> defense actions that can be executed by the various systems that = those >> actions target. Further, these COAs can be coordinated and deployed = across >> heterogeneous cyber security systems such that both the actions = requested >> and the resultant outcomes may be monitored and verified. These = actions >> will be referenceable in a connected data structure that provides = support for >> connected data object and efficient operational use of those data = objects >> such as Threat Actors, Campaigns, Intrusion Sets, Malware, Attack = Patterns, >> and other adversarial techniques, tactics, and procedures (TTPs). >=20 > What are "data objects"? I recommend merely describing the class of = data that needs to be exchanged in the COA; and with whom and avoid = further specificity that would require additional definitions.=20 >=20 > Why are "Threat Actors, Campaigns ..." capitalized like proper nouns = in this context (I appreciate that these are STIX objects). >=20 >>> Where possible the working group will leverage existing efforts that = *may* >> define the atomic actions to be included in a process or sequence.=20 >=20 > I recommend you specify these related efforts. >=20 >> The >> working group will not consider how shared actions are used/enforced, >> except where a response is expected for such a received shared action = by a >> receiving party. It will also focus on the requirements for the = correct >> construction and correct distribution of the structured actions and = their >> corresponding interfaces and protocols. >=20 > Is "requirements for the correct construction and ..." the same thing = as specifying a MTI protocol or data model? >=20 >>> # Goals >>> This working group has the following major goals: >>> * Document the use cases and requirements >>> * Identify and document the system functions and roles that must >> exist with associated protocols for a coordinated threat response = system to >> operate effectively >=20 > I initially read this as an informational architecture draft per the = deliverable list. However, the language "must exist" suggests something = stronger. Is this the architecture draft? >=20 > Are the "associated protocols" different than the ones that would be = specified by this WG? >=20 > What is the dependency between the "roles"/"system functions" = documentation and the data model and protocol work? >=20 >>> * Identify and document the configuration for a series of = protocols >> that can be used to distribute courses of action in both direct = delivery and >> publish-subscribe methods >=20 > "Identify and document" reads to me like a new protocol won't be = specified. However, the deliverable list states that there will be a = "CACAO Distribution and Response Application Layer Protocol". Could you = please clarity. If you intend to make a standard track document with a = protocol, I recommend you use the verb "specify"/"standardize" >=20 >>> * Identify and document the mechanism(s) required to monitor, >> report and alert on effective distribution of CACAO actions and the = potential >> threat response to those actions >=20 > To which deliverable does this map? What are "mechanisms"? >=20 >>> * Create an information and data model that can capture and >> enable collaborative courses of action (sometimes called playbooks) = that >> will be used in the coordinated threat response systems >=20 > This text references information and data models, the deliverables = only mention a data model. Is the information model going to be = specified in the JSON draft? >=20 >>> * Define and create a series of tests and documents to assist = with >> interoperability of the various systems involved in the coordinated = threat >> response system. >=20 > This bullet doesn't appear to have a corresponding item in the = deliverable section. Furthermore, per the language "series of tests and = documents" how will the "tests" manifest if not in a document? If it's = not in a draft, it is not a WG work item. >=20 >>> # Deliverables >>> The working group plans to create informational and standards track >> documents, some of which may be published through the IETF RFC = stream. >>> * CACAO Use Cases and Requirements >>> * CACAO Functional Architecture: Roles and Interfaces >>> * CACAO Interface Specification >>> * CACAO JSON Data Model >=20 > draft-jordan-cacao-introduction made reference to a CBOR data model. = Is that still in scope? >=20 >>> * CACAO Distribution and Response Application Layer Protocol >>>=20 >=20 > IMO, it would be clearer to collapse the current list of goals with = the deliverables. =20 >=20 > Roman >=20 > --=20 > Cacao mailing list > Cacao@ietf.org > https://www.ietf.org/mailman/listinfo/cacao --Apple-Mail=_1EEA6D1C-022B-489F-8F70-CEB241A529BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Roman,

Thank you for the very careful and thoughtful response. =  We will work on this and try and produce an updated version in the = coming days.

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."


Hello!

I've reviewed the latest = (01/18/2019) charter language per https://mailarchive.ietf.org/arch/msg/cacao/FErdmnk2MhOqG7kkDk2= oBIthbqQ.  As is, I have a few concerns.

In broad strokes:
** The notional output of = the WG isn't clear
** There are no references to related = work in the IETF (e.g., MILE, I2NSF) or in the community
See inline comments of the charter text for additional = comments.

# Problem
Threat Actors and Intrusion Sets are = advancing at an increasing rate
relative to an = organization's ability to defend against and respond to cyber
attacks.

Editorial: = "advancing" how?  I'm stumbling with this opening sentence.

In = addition, it is common that defenders need to manually identify
and process prevention, mitigation, and remediation steps in = order to
protect their systems, networks, data, and users. =

I agree with this text in = that manual identification of what to do in response to an attack is = prevalent.  However, I push back on the "need" to manually process = prevention, mitigation and remediation steps -- there is a lot of = options for IT automation/SecOps (ansible, puppet, etc.) once the action = is encoded.

There is also currently no
standard means to = easily and dynamically share proposed prevention,
mitigation, or remediation steps and the operational = experience gained
from these attacks or their associated = successful responses among a trusted
set of = organizations.

Concur. =  It's the lack of a standardized approach to share these COAs = across organizations and interoperability across tech stacks which = strikes me as a/the key issue.


Due to the increasing sophistication and amplitude of cyber = attacks the
need for a secure collaborative = set of systems providing coordinated
detection and = response across hosts, networks, and security infrastructure
has raised significantly. This solution is necessary to = effectively respond to
threats in machine relevant time. = While some attacks may be well known to
certain security = experts and researchers they are often not documented in a
way that would enable automated prevention, mitigation, or = remediation.

Key to this coordinated cyber attack response is a = coordinated threat
response including a = standard information model; a set of functional
capabilities, associated interfaces, and protocols. These key = requirements
would be defined in each of the system = components across host; network
and security = infrastructure to ensure that each system can work together in a
coordinated manner.

For me, these two paragraphs didn't add anything describing = the problem.  They read more as a solution to the first paragraph = which seems more appropriate in later parts of the charter text.

# Working Group
To enable = efficient collaboration and facilitate the rapid sharing of
preventative, mitigative, and remediative = actions this working group will
focus on defining the set = of technologies (protocols, interfaces, functional
capabilities, and information model) required to detect, = prevent, mitigate,
and remediate threats.

IMO, the statement "[T]his = working group will focus on defining the set of technologies to detect, = prevent, mitigate and remediate threat" seems too broad.  This WG = seems to be proposing a particular solution, automated COA exchange. =  Furthermore, I see no deliverables related to threat detection.

Editorial: The sentence states "prevent, = mitigate and remediate" twice.  

Editorial: I recommend the first sentence of this section to = be a declarative statement of what this WG would do.  The simpler = language used in the slide #2 of the 10/24/2018 Intro Webex, https://mailarchive.ietf.org/arch/msg/cacao/-cgdaJG6uM71IeNwp3o= xl6rRQiE, is to the point.

This solution will also define the = machine-readable
actions to enable an action-oriented = defensive system. This effort will focus
on providing the = functionality requirements for each system that would
participate in a coordinated threat response; the interfaces = they should
support including the transport mechanism used = and finally the information
model across those systems to = enable the coordinated actions in a
structured secure = manner.

This is the third time = in the text where the list of functional requirements, interfaces, and = info model is enumerated as a need.  The first time was in the = Problem section, the second was parenthetically in the previous = paragraph, and it will again be discussed in the Goals and Deliverables. =  I don't think this paragraph is needed.  

Each collaborative course of action will consist of a = sequence of cyber
defense actions that can be = executed by the various systems that those
actions target. = Further, these COAs can be coordinated and deployed across
heterogeneous cyber security systems such that both the = actions requested
and the resultant outcomes may be = monitored and verified. These actions
will be = referenceable in a connected data structure that provides support for
connected data object and efficient operational use of those = data objects
such as Threat Actors, Campaigns, Intrusion = Sets, Malware, Attack Patterns,
and other adversarial = techniques, tactics, and procedures (TTPs).
What are "data objects"?  I recommend merely describing = the class of data that needs to be exchanged in the COA; and with whom = and avoid further specificity that would require additional definitions. =

Why are "Threat Actors, Campaigns ..." = capitalized like proper nouns in this context (I appreciate that these = are STIX objects).

Where possible the = working group will leverage existing efforts that *may*
define the atomic actions to be included in a = process or sequence.

I = recommend you specify these related efforts.

The
working= group will not consider how shared actions are used/enforced,
except where a response is expected for such a received = shared action by a
receiving party. It will also focus on = the requirements for the correct
construction and correct = distribution of the structured actions and their
corresponding interfaces and protocols.

Is "requirements for the correct = construction and ..." the same thing as specifying a MTI protocol or = data model?

# Goals
This= working group has the following major goals:
* = Document the use cases and requirements
* = Identify and document the system functions and roles that must
exist with associated protocols for a = coordinated threat response system to
operate = effectively

I initially read = this as an informational architecture draft per the deliverable list. =  However, the language "must exist" suggests something stronger. =  Is this the architecture draft?

Are = the "associated protocols" different than the ones that would be = specified by this WG?

What is the = dependency between the "roles"/"system functions" documentation and the = data model and protocol work?

* = Identify and document the configuration for a series of protocols
that can be used to distribute courses of action = in both direct delivery and
publish-subscribe methods

"Identify and document" reads to = me like a new protocol won't be specified.  However, the = deliverable list states that there will be a "CACAO Distribution and = Response Application Layer Protocol".  Could you please clarity. =  If you intend to make a standard track document with a protocol, I = recommend you use the verb "specify"/"standardize"

= * Identify and document the mechanism(s) required to monitor,
report and alert on effective distribution of = CACAO actions and the potential
threat response to those = actions

To which deliverable = does this map?  What are "mechanisms"?

= * Create an information and data model that can capture and
enable collaborative courses of action = (sometimes called playbooks) that
will be used in the = coordinated threat response systems

This text references information and data models, the = deliverables only mention a data model.  Is the information model = going to be specified in the JSON draft?

= * Define and create a series of tests and documents to assist = with
interoperability of the various systems = involved in the coordinated threat
response system.

This bullet doesn't appear to = have a corresponding item in the deliverable section.  Furthermore, = per the language "series of tests and documents" how will the "tests" = manifest if not in a document?  If it's not in a draft, it is not a = WG work item.

# Deliverables
The working group plans to create informational and standards = track
documents, some of which may be = published through the IETF RFC stream.
* CACAO Use Cases and = Requirements
* CACAO Functional Architecture: = Roles and Interfaces
* CACAO Interface = Specification
* CACAO JSON Data Model

draft-jordan-cacao-introduction made reference to a CBOR data = model.  Is that still in scope?

= * CACAO Distribution and Response Application Layer Protocol


IMO, = it would be clearer to collapse the current list of goals with the = deliverables.  

Roman

--
Cacao mailing list
Cacao@ietf.org
https://www.ietf.org/mailman/listinfo/cacao

= --Apple-Mail=_1EEA6D1C-022B-489F-8F70-CEB241A529BB-- From nobody Mon Jan 28 09:07:21 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B780131088 for ; Mon, 28 Jan 2019 09:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKMmR8wJ9N_x for ; Mon, 28 Jan 2019 09:07:17 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEA913107A for ; Mon, 28 Jan 2019 09:07:17 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id b5so20425271iti.2 for ; Mon, 28 Jan 2019 09:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=J6vAikyZoKEVOHa0+1dtUYLIcieYxBuq+zky3NZ8LRA=; b=qh5AkZlySlEl70XsPzVg6w1e+Grg3AaJh/giH4REUpCJVl1iRcHDVO4aenLjMz3Mh+ PiuCwXpQ687NcGEpyHCz3/l4/Io1M3AtGA8iW+ZM1FQpPGiJJaD1URn0ms0tVXBHdjpg AIvQiNQFXcQGNqdni+FX2ku7QIlK8VgpqZvJctOTpf+gzXahwWrJnQsDPiuBkMfiz2lq oT78WcSdpr4OLGbWim3Zylqi2LC8P+TCyiQbXpN8TFbdXw2XlCTnr+eGrUvJwMZIPsZ/ D782peXOTU8oBigTp5fa9BPxmJGi51s3WeOAxq6IQcMFuxgObAFTv1vRLX+z+tlE99pI wQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=J6vAikyZoKEVOHa0+1dtUYLIcieYxBuq+zky3NZ8LRA=; b=gFVIj84I7viWGVwrzBBlPd1qFXDqGRTqd6u0fMPI9YhXCfj54u7G8235NClCtGNW/l 4FGizixrc1vnnU/Zw7bwuhFDzViaE9P9qNcu3hVropNrqK+8LVogzUFYt1jSFYN9JkmE RzeQ+ld9kPcf4yKfQPVE3czLSKx/2Ec/b6DJMQ6TBoUezcJqyDhUy2c6rt/iVrBjwFYD rxa5mSooPXF7d45A3JqtakPmnYqRmBSaPcM4+lZTz4mCD0iLrhqbKvKQ+AnM7zaBnhFX kp9Eo7GvpBv7C6/CR1WrcJWoHBN+ToU0po1u4aHG+vBHsMVyMoAvXKVnpVBdJn4yxHam dqlw== X-Gm-Message-State: AJcUukefn4WVv/XVQsPvLlSlwy1gJURCes8fqo/RnBlsXzl9eUY5OzjQ SkFothMCplHKxLZwIFGhYpZ03QeT X-Google-Smtp-Source: ALg8bN64eWVhwINmM0IdP47Fs+dmiG/TmzYlXnV5YJ/QrVff4NwXb9JYOvr5oKI3QwUFayZwoIZgNQ== X-Received: by 2002:a24:5f4d:: with SMTP id r74mr10684794itb.170.1548695236487; Mon, 28 Jan 2019 09:07:16 -0800 (PST) Received: from ?IPv6:2605:a601:a028:986:380d:aebe:1454:b28? ([2605:a601:a028:986:380d:aebe:1454:b28]) by smtp.gmail.com with ESMTPSA id f13sm13773236iol.82.2019.01.28.09.07.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jan 2019 09:07:15 -0800 (PST) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_33DE90ED-1515-4241-82BD-B42184E578E4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Mon, 28 Jan 2019 10:06:57 -0700 To: cacao@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cacao] Updated Charter version 02 X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 17:07:20 -0000 --Apple-Mail=_33DE90ED-1515-4241-82BD-B42184E578E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, We tried to address all of the comments and feedback from Roman in this = version of the Charter. Please review. If there are other changes, = please let us know. https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ = ### BEGIN # Introduction To defend against threat actors and advanced attacker toolkits known as = intrusion sets, organizations need to manually identify, create, and = document prevention, mitigation, and remediation steps. These steps when = grouped together into a course of action (COA) / playbook are used to = protect systems, networks, data, and users. The problem is, once these = steps have been created there is no standardized and structured way to = document them, monitor them for correct execution, or easily and = dynamically share them across organizational boundaries and technology = stacks. This working group will create a standard that implements the playbook = model based on current industry best practices for cybersecurity, such = as those defined in the IACD work from Johns Hopkins APL.=20 This solution will: 1. enable the creation and documentation of COAs in a structured = machine-readable format 2. enable organizations to collaborate on COAs 3. enable the sharing and distribution of COAs across organizational = boundaries and technology stacks 4. enable the monitoring and verification of deployed COAs.=20 This solution will contain at a minimum; a standard data model, a set of = functional capabilities and associated interfaces, and a mandatory to = implement protocol.=20 Each collaborative course of action will consist of a sequence of cyber = defense actions that can be executed by the various systems that those = actions target. Further, these COAs can be coordinated and deployed = across heterogeneous cyber security systems such that both the actions = requested and the resultant outcomes may be monitored and verified. = These actions will be referenceable in a connected data structure that = provides support for connected data such as threat actors, campaigns, = intrusion sets, malware, attack patterns, and other adversarial = techniques, tactics, and procedures (TTPs). Where possible the working group will leverage existing efforts, like = OpenC2 that *may* define the atomic actions to be included in a process = or sequence. The working group will not consider how shared actions are = used/enforced, except where a response is expected for a specific action = or step. # Goals and Deliverables This working group has the following major goals and deliverables. Some = of the deliverables may be published through the IETF RFC stream as = informational or standards track documents. - CACAO Use Cases and Requirements - Document the use cases and requirements - CACAO Functional Architecture: Roles and Interfaces - Identify and document the system functions and roles that are = needed to enable Collaborative Courses of Action. - CACAO Protocol Specification - Identify and document the configuration for a series of mandatory = to implement protocols that can be used to distribute courses of action = in both direct delivery and publish-subscribe methods - CACAO Distribution and Response Application Layer Protocol - Identify and document the requirements to effectively monitor, = report, and alert on the distribution of CACAO actions and the potential = threat response to those actions - CACAO JSON Data Model - Create a JSON data model (and possibly a general information model = and CBOR model) that can capture and enable collaborative courses of = action - CACAO Interoperability Test Documents - Define and create a series of tests and documents to assist with = interoperability of the various systems involved.=20 The working group may decide to not publish the use cases and = requirements as RFCs. That decision will be made during the lifetime of = the working group.=20 ### END Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." --Apple-Mail=_33DE90ED-1515-4241-82BD-B42184E578E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii All,

We = tried to address all of the comments and feedback from Roman in this = version of the Charter.  Please review.  If there are other = changes, please let us know.





# Introduction

To defend against threat actors and advanced = attacker toolkits known as intrusion sets, organizations need to = manually identify, create, and document prevention, mitigation, and = remediation steps. These steps when grouped together into a course of = action (COA) / playbook are used to protect systems, networks, data, and = users. The problem is, once these steps have been created there is no = standardized and structured way to document them, monitor them for = correct execution, or easily and dynamically share them across = organizational boundaries and technology stacks.

This = working group will create a standard that implements the playbook model = based on current industry best practices for cybersecurity, such as = those defined in the IACD work from Johns Hopkins APL.

This = solution will:

1. enable = the creation and documentation of COAs in a structured machine-readable = format
2. enable = organizations to collaborate on COAs
3. enable the sharing and distribution of COAs = across organizational boundaries and technology stacks
4. enable the monitoring and verification of = deployed COAs.

This = solution will contain at a minimum; a standard data model, a set of = functional capabilities and associated interfaces, and a mandatory to = implement protocol.

Each = collaborative course of action will consist of a sequence of cyber = defense actions that can be executed by the various systems that those = actions target. Further, these COAs can be coordinated and deployed = across heterogeneous cyber security systems such that both the actions = requested and the resultant outcomes may be monitored and verified. = These actions will be referenceable in a connected data structure that = provides support for connected data such as threat actors, campaigns, = intrusion sets, malware, attack patterns, and other adversarial = techniques, tactics, and procedures (TTPs).

Where = possible the working group will leverage existing efforts, like OpenC2 = that *may* define the atomic actions to be included in a process or = sequence. The working group will not consider how shared actions are = used/enforced, except where a response is expected for a specific action = or step.

# Goals and = Deliverables

This = working group has the following major goals and deliverables. Some of = the deliverables may be published through the IETF RFC stream as = informational or standards track documents.

- CACAO = Use Cases and Requirements
=   - Document the use cases and requirements
- CACAO Functional Architecture: Roles and = Interfaces
=   - Identify and document the system functions and roles that = are needed to enable Collaborative Courses of Action.
- CACAO Protocol Specification
  - Identify and document the = configuration for a series of mandatory to implement protocols that can = be used to distribute courses of action in both direct delivery and = publish-subscribe methods
- CACAO = Distribution and Response Application Layer Protocol
  - Identify and document the = requirements to effectively monitor, report, and alert on the = distribution of CACAO actions and the potential threat response to those = actions
- CACAO = JSON Data Model
=   - Create a JSON data model (and possibly a general = information model and CBOR model) that can capture and enable = collaborative courses of action
- CACAO = Interoperability Test Documents
=   - Define and create a series of tests and documents to = assist with interoperability of the various systems involved. =

The working = group may decide to not publish the use cases and requirements as RFCs. = That decision will be made during the lifetime of the working group. =




Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

= --Apple-Mail=_33DE90ED-1515-4241-82BD-B42184E578E4-- From nobody Tue Jan 29 15:38:13 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48E113108E for ; Tue, 29 Jan 2019 15:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHyB_yvjYuZs for ; Tue, 29 Jan 2019 15:38:06 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1B81310A9 for ; Tue, 29 Jan 2019 15:38:06 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0TNc4r5003316; Tue, 29 Jan 2019 18:38:04 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x0TNc4r5003316 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1548805084; bh=3BDw9DZOxIBStb7ketNTzEmo9fw61hE8VbxKeJKZ4VA=; h=From:To:Subject:Date:References:In-Reply-To:From; b=JHvRl5TG14IRcqb7G1rxeU4b8TsEuMhX4d+o933+M9KssunzKsxRySi2R7GBQYYf6 0Y7Onm9rO05RCFb6JaBCS6z80BFnhertgqGGVeTu1K7PtFcWr3gW/z/b6DM8sWqn5h ibJDTQE/wiVYWeBoetAvFVKHGcP8a4daZkCComUc= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0TNc3Kk018887; Tue, 29 Jan 2019 18:38:03 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Tue, 29 Jan 2019 18:38:03 -0500 From: Roman Danyliw To: Bret Jordan , "cacao@ietf.org" Thread-Topic: [Cacao] Updated Charter version 02 Thread-Index: AQHUtyv24L3bFhjJp0aBzrlhMSFZDKXG1yUw Date: Tue, 29 Jan 2019 23:38:02 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01857A064B@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01857A064Bmarathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cacao] Updated Charter version 02 X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 23:38:12 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01857A064Bmarathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! > From: Cacao [mailto:cacao-bounces@ietf.org] On Behalf Of Bret Jordan > Sent: Monday, January 28, 2019 12:07 PM > To: cacao@ietf.org > Subject: [Cacao] Updated Charter version 02 > > All, > > We tried to address all of the comments and feedback from Roman in this > version of the Charter. Please review. If there are other changes, plea= se let > us know. Thanks for responding to my comments and revising the proposed text. I hav= e a few more comments noted inline. > https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ > > > > ### BEGIN > > # Introduction > To defend against threat actors and advanced attacker toolkits known as > intrusion sets, organizations need to manually identify, create, and > document prevention, mitigation, and remediation steps. Recommend: s/To defend against threat actors and advanced attacker toolkits known as i= ntrusion sets,/To defend against threat actors and their techniques, tactic= s and procedures, organizations need .../ IMO, you would need this work whether the attacker is "advanced" or not. F= urthermore, I think we have different definitions of "intrusion sets". > These steps when > grouped together into a course of action (COA) / playbook are used to > protect systems, networks, data, and users. The problem is, once these > steps have been created there is no standardized and structured way to > document them, monitor them for correct execution, or easily and > dynamically share them across organizational boundaries and technology > stacks. What does "dynamically share" mean in this context? I understand "easily s= hare". Do you mean share with organizations without pre-agreed arrangement= s? > This working group will create a standard that implements the playbook > model based on current industry best practices for cybersecurity, such as > those defined in the IACD work from Johns Hopkins APL. I'm not sure how to take this reference. Will some artifact from IACD be b= rought in as the starting point for the work? > This solution will: > > 1. enable the creation and documentation of COAs in a structured machine- > readable format Check. This is clear. > 2. enable organizations to collaborate on COAs To me, "collaborate" implies a back-and-forth refinement of the COA in an a= utomated way with the protocol. Are you suggesting that this level of work= flow is needed, or is it something simpler like "sharing" or "exchanging" (= per the language used in the first paragraph). I'm questioning the need fo= r #2 given #3 if you're envisioning a simpler workflow. > 3. enable the > sharing and distribution of COAs across organizational boundaries and > technology stacks Check. This is clear. > 4. enable the monitoring and verification of deployed > COAs. Editorial: the language in #3 and #4 seems like a duplicate to the text alr= eady stated in the first paragraph. Do you mean providing a data format/protocol to convey status about the exe= cution of the COAs between organizations (e.g., "Org-2, I got your COA-A an= d applied it")? Or a format/protocol to actually query the devices (or a s= him/proxy in that tasks the devices) executing the COAs to determine what h= appened (e.g., "Router-1 is ACL-1 applied?"). Is the language about capabi= lities/interfaces below enabling that verification? > This solution will contain at a minimum; a standard data model, How is this text different than what was stated in "[t]his solution will: 1= . Enable the creation and documentation ..." > a set of > functional capabilities and associated interfaces, and a mandatory to > implement protocol. The notion of functional capabilities and associated interfaces is introduc= ed here. I think it is worth adding a little text to refine what is meant = by that. > Each collaborative course of action will consist of a sequence of cyber > defense actions that can be executed by the various systems that those > actions target. Further, these COAs can be coordinated and deployed acros= s > heterogeneous cyber security systems such that both the actions requested > and the resultant outcomes may be monitored and verified. These actions > will be referenceable in a connected data structure that provides support= for > connected data such as threat actors, campaigns, intrusion sets, malware, > attack patterns, and other adversarial techniques, tactics, and procedure= s > (TTPs). Specifying threat actors, campaigns, etc seems like it has been done by wor= k such as OASIS STIX or MILE IODEF. I recommend saying that this COAs form= at will provide a means to reference this class of data through a variety o= f previously developed formats. You might have meant that by "these action= s will be referenceable in ..." but I would be clearer. > Where possible the working group will leverage existing efforts, like Ope= nC2 > that *may* define the atomic actions to be included in a process or > sequence. The working group will not consider how shared actions are > used/enforced, except where a response is expected for a specific action = or > step. What does the "*may*" mean in this context? Perhaps "Where possible the wo= rking will consider existing work like OASIS OpenC2, IETF I2NSF, ..." > # Goals and Deliverables > This working group has the following major goals and deliverables. Some o= f > the deliverables may be published through the IETF RFC stream as > informational or standards track documents. > > - CACAO Use Cases and Requirements > - Document the use cases and requirements s/Document/Specify/ > - CACAO Functional Architecture: Roles and Interfaces > - Identify and document the system functions and roles that are needed = to > enable Collaborative Courses of Action. s/Identify and document/Specify/ > - CACAO Protocol Specification > - Identify and document the configuration for a series of mandatory to > implement protocols that can be used to distribute courses of action in b= oth > direct delivery and publish-subscribe methods s/Identify and document/Standardize/ What's a "configuration for a protocol"? Is that a profile for something t= hat already exists? Is that saying there is not a new protocol to develop = only a matter of choosing one? It isn't uncommon to include a reference to what starting points for these = protocols might be. IMO, "series of MTI protocols" boxes in the work too much. Might there be = a case for an alternative to the MTI protocol? > - CACAO Distribution and Response Application Layer Protocol > - Identify and document the requirements to effectively monitor, report= , > and alert on the distribution of CACAO actions and the potential threat > response to those actions My questions above will help me understand this item better. > - CACAO JSON Data Model > - Create a JSON data model (and possibly a general information model an= d > CBOR model) that can capture and enable collaborative courses of action Recommend removing the parenthetical, or making an explicit bullet for an i= nformation model. CBOR would be another data model. > - CACAO Interoperability Test Documents > - Define and create a series of tests and documents to assist with > interoperability of the various systems involved. Does this need to be an informational RFC or can it just be put in a wiki? = Would this be published? I ask because the use cases/requirements were ca= lled out as potentially not being published. > The working group may decide to not publish the use cases and > requirements as RFCs. That decision will be made during the lifetime of t= he > working group. > > > > ### END Regards, Roman --_000_359EC4B99E040048A7131E0F4E113AFC01857A064Bmarathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

> From: Cacao [mailto:cac= ao-bounces@ietf.org] On Behalf Of Bret Jordan

> Sent: Monday, January 28, 2019 12:07 PM=

> To: cacao@ietf.org

> Subject: [Cacao] Updated Charter version 02<= o:p>

>

> All,

>

> We tried to address all of the comments and = feedback from Roman in this

> version of the Charter.  Please review.=  If there are other changes, please let

> us know.

 

Thanks for responding to my comments and revising= the proposed text.  I have a few more comments noted inline.

> https://datatracker.i= etf.org/doc/draft-jordan-cacao-charter/

>

>

>

> ### BEGIN

>

> # Introduction

> To defend against threat actors and advanced= attacker toolkits known as

> intrusion sets, organizations need to manual= ly identify, create, and

> document prevention, mitigation, and remedia= tion steps.

 

Recommend:

s/To defend against threat actors and advanced at= tacker toolkits known as intrusion sets,/To defend against threat actors an= d their techniques, tactics and procedures, organizations need …/

 

IMO, you would need this work whether the attacke= r is “advanced” or not.  Furthermore, I think we have diff= erent definitions of “intrusion sets”.

 

> These steps when

> grouped together into a course of action (CO= A) / playbook are used to

> protect systems, networks, data, and users. = The problem is, once these

> steps have been created there is no standard= ized and structured way to

> document them, monitor them for correct exec= ution, or easily and

> dynamically share them across organizational= boundaries and technology

> stacks.

 

What does “dynamically share” mean in= this context?  I understand “easily share”.  Do you = mean share with organizations without pre-agreed arrangements?

 

> This working group will create a standard th= at implements the playbook

> model based on current industry best practic= es for cybersecurity, such as

> those defined in the IACD work from Johns Ho= pkins APL.

 

I’m not sure how to take this reference.&nb= sp; Will some artifact from IACD be brought in as the starting point for th= e work?

 

> This solution will:

>

> 1. enable the creation and documentation of = COAs in a structured machine-

> readable format

 

Check.  This is clear.

 

> 2. enable organizations to collaborate on CO= As

 

To me, “collaborate” implies a back-a= nd-forth refinement of the COA in an automated way with the protocol. = Are you suggesting that this level of workflow is needed, or is it somethi= ng simpler like “sharing” or “exchanging” (per the language used in the first paragraph).  I’m questioning the nee= d for #2 given #3 if you’re envisioning a simpler workflow.

 

> 3. enable the

> sharing and distribution of COAs across orga= nizational boundaries and

> technology stacks

 

Check.  This is clear.

 

> 4. enable the monitoring and verification of= deployed

> COAs.

 

Editorial: the language in #3 and #4 seems like a= duplicate to the text already stated in the first paragraph.

 

Do you mean providing a data format/protocol to c= onvey status about the execution of the COAs between organizations (e.g., &= #8220;Org-2, I got your COA-A and applied it”)?  Or a format/pro= tocol to actually query the devices (or a shim/proxy in that tasks the devices) executing the COAs to determine what happened (= e.g., “Router-1 is ACL-1 applied?”).  Is the language abou= t capabilities/interfaces below enabling that verification?

> This solution will contain at a minimum; a s= tandard data model,

 

How is this text different than what was stated i= n “[t]his solution will: 1. Enable the creation and documentation = 230;”

 

>  a set of

> functional capabilities and associated inter= faces, and a mandatory to

> implement protocol.

 

The notion of functional capabilities and associa= ted interfaces is introduced here.  I think it is worth adding a littl= e text to refine what is meant by that.

 

> Each collaborative course of action will con= sist of a sequence of cyber

> defense actions that can be executed by the = various systems that those

> actions target. Further, these COAs can be c= oordinated and deployed across

> heterogeneous cyber security systems such th= at both the actions requested

> and the resultant outcomes may be monitored = and verified. These actions

> will be referenceable in a connected data st= ructure that provides support for

> connected data such as threat actors, campai= gns, intrusion sets, malware,

> attack patterns, and other adversarial techn= iques, tactics, and procedures

> (TTPs).

 

Specifying threat actors, campaigns, etc seems li= ke it has been done by work such as OASIS STIX or MILE IODEF.  I recom= mend saying that this COAs format will provide a means to reference this cl= ass of data through a variety of previously developed formats.  You might have meant that by “these actions= will be referenceable in …” but I would be clearer.=

 

> Where possible the working group will levera= ge existing efforts, like OpenC2

> that *may* define the atomic actions to be i= ncluded in a process or

> sequence. The working group will not conside= r how shared actions are

> used/enforced, except where a response is ex= pected for a specific action or

> step.

 

What does the “*may*” mean in this co= ntext?  Perhaps “Where possible the working will consider existi= ng work like OASIS OpenC2, IETF I2NSF, …”

 

> # Goals and Deliverables

> This working group has the following major g= oals and deliverables. Some of

> the deliverables may be published through th= e IETF RFC stream as

> informational or standards track documents.<= o:p>

>

> - CACAO Use Cases and Requirements

>   - Document the use cases and req= uirements

 

s/Document/Specify/

 

> - CACAO Functional Architecture: Roles and I= nterfaces

>   - Identify and document the syst= em functions and roles that are needed to

> enable Collaborative Courses of Action.=

 

s/Identify and document/Specify/

 

> - CACAO Protocol Specification

>   - Identify and document the conf= iguration for a series of mandatory to

> implement protocols that can be used to dist= ribute courses of action in both

> direct delivery and publish-subscribe method= s

 

s/Identify and document/Standardize/

 

What’s a “configuration for a protoco= l”?  Is that a profile for something that already exists?  = Is that saying there is not a new protocol to develop only a matter of choo= sing one?

 

It isn’t uncommon to include a reference to= what starting points for these protocols might be.

 

IMO, “series of MTI protocols” boxes = in the work too much.  Might there be a case for an alternative to the= MTI protocol?

 

> - CACAO Distribution and Response Applicatio= n Layer Protocol

>   - Identify and document the requ= irements to effectively monitor, report,

> and alert on the distribution of CACAO actio= ns and the potential threat

> response to those actions

 

My questions above will help me understand this i= tem better.

 

> - CACAO JSON Data Model

>   - Create a JSON data model (and = possibly a general information model and

> CBOR model) that can capture and enable coll= aborative courses of action

 

Recommend removing the parenthetical, or making a= n explicit bullet for an information model.  CBOR would be another dat= a model.

 

> - CACAO Interoperability Test Documents=

>   - Define and create a series of = tests and documents to assist with

> interoperability of the various systems invo= lved.

 

Does this need to be an informational RFC or can = it just be put in a wiki?  Would this be published?  I ask becaus= e the use cases/requirements were called out as potentially not being publi= shed.

 

> The working group may decide to not publish = the use cases and

> requirements as RFCs. That decision will be = made during the lifetime of the

> working group.

>

>

>

> ### END

 

Regards,

Roman

 

--_000_359EC4B99E040048A7131E0F4E113AFC01857A064Bmarathon_-- From nobody Thu Jan 31 15:54:14 2019 Return-Path: X-Original-To: cacao@ietfa.amsl.com Delivered-To: cacao@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C09131100 for ; Thu, 31 Jan 2019 15:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYBZ1EvFG1Ul for ; Thu, 31 Jan 2019 15:54:09 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E3C13103A for ; Thu, 31 Jan 2019 15:54:09 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id i145so6603052ita.4 for ; Thu, 31 Jan 2019 15:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=04ECVQS+sxWh7QGrpX6ka5lBg1omuxqWEu99Gjqtaok=; b=dS4I2ewmBtjgkLOcQewGgRQcSyRgYGUS24C8TWzazA0CizWmYX0h1PG46f6rV9bGdC MxTJJ5f9V1UOEN1Ii02F2rvXaH4GrDiuEeRnbAxxy7/y9LTWwS+ud1rRjRXVzV701YtA 7YlKcv3+vXDhfLxAcUuUMBWsrOLgWZiIg4jCpo/FPs4I27lAbu1WzWkdSq2b2QWr/23r n061mtC1otMjnc8bL2rz593haJmUjLRaZ0EaTI/sii3sRiLrX/0neM357Lr8eT8wVqrB WtKmsdmjyepnW5ttRObjBWSf7QErZnYZrASnxGSHUTI8geDRLPfCnfkYRaDv3a9TALlt 8KsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=04ECVQS+sxWh7QGrpX6ka5lBg1omuxqWEu99Gjqtaok=; b=F9qqJiWmRjldOhhQk/EP1FSNsNDny5jC1ErcoRpBhLOYH5AlAj5hfZjhZUQRWRZroI 6Z7EYgjkNnOafqQdwqBjXSrJVwxqT6p5FyWpfoEfDte1XKcY+zxjlakPAM4IDfYvHR9e HJzOnn0FbYoe+3xRUsehnXz1648YSvN/R9rq1eW09LOugUpDbPXrOMEyADvZi3z8qUTl DZk3XNlVCKgkVZOXduCijz9vYHAgNHDakUsEg2p8wF0AEdVllreQweISF/5/yYDwzRIk G+evwbbs3a/nfig6h+Kx+w5LTblHrStd0SPmgLbhjEq+01wElhAyi/nIxa+fOeAoBdjs YqxA== X-Gm-Message-State: AJcUukdyWfUGbW1cUGhrLl7hi2YtCcMpWUs87NliSUqtVWo7+uniyB+L toFHk+cXRgYkHaQs68EFl/sxeypS X-Google-Smtp-Source: ALg8bN4TV5ErxTWVx4VukQ2b5Rfz6qdrZuUgXrlAORXK7oqzE7Y84gMFFZPxk3zKI2t2k+cCkGfRSw== X-Received: by 2002:a02:6284:: with SMTP id d126mr24218804jac.120.1548978848147; Thu, 31 Jan 2019 15:54:08 -0800 (PST) Received: from ?IPv6:2605:a601:a028:986:442c:8aed:43f1:edf? ([2605:a601:a028:986:442c:8aed:43f1:edf]) by smtp.gmail.com with ESMTPSA id 195sm445838itm.2.2019.01.31.15.54.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 15:54:07 -0800 (PST) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_3B63EF84-822B-434D-A971-1428D09DAFB1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Thu, 31 Jan 2019 16:53:46 -0700 To: cacao@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cacao] Updated Charter version 03 X-BeenThere: cacao@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Collaborative Automated Course of Action Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 23:54:13 -0000 --Apple-Mail=_3B63EF84-822B-434D-A971-1428D09DAFB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, Thanks for all of the great feedback on the charter text. We have = updated the document to address all comments that we have received and = are releasing a new version of the text. You can see it here: = https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ = and = copied below. ### BEGIN # Introduction To defend against threat actors and their tactics, techniques, and = procedures, organizations need to manually identify, create, and = document prevention, mitigation, and remediation steps. These steps when = grouped together into a course of action (COA) / playbook are used to = protect systems, networks, data, and users. The problem is, once these = steps have been created there is no standardized and structured way to = document them, verify they were correctly executed, or easily share them = across organizational boundaries and technology stacks. This working group will create a standard that implements the playbook = model based on current industry best practices for cybersecurity.=20 This solution will specifically enable: 1. the creation and documentation of COAs in a structured = machine-readable format 2. organizations to perform attestations on COAs 3. the sharing and distribution of COAs across organizational = boundaries and technology stacks 4. the verification of deployed COAs.=20 This solution will contain (at a minimum) a standard JSON based data = model, a defined set of functional capabilities and associated = interfaces, and a mandatory to implement protocol. This solution will = also provide a data model for actuators to confirm the status of the COA = execution, however, it will be agnostic of how the COA is implemented by = the actuator. Each collaborative course of action will consist of a sequence of cyber = defense actions that can be executed by the various systems that can act = on those actions. Further, these COAs will be coordinated and deployed = across heterogeneous cyber security systems such that both the actions = requested and the resultant outcomes may be verified. These COA actions = will be referenceable in a connected data structure like the OASIS STIX = V2 model that provides support for connected data such as threat actors, = campaigns, intrusion sets, malware, attack patterns, and other = adversarial techniques, tactics, and procedures (TTPs).=20 Where possible the working group will consider existing efforts, like = OASIS OpenC2 and IETF I2NSF that define the atomic actions to be = included in a process or sequence. The working group will not consider = how shared actions are used/enforced, except where a response is = expected for a specific action or step. # Goals and Deliverables This working group has the following major goals and deliverables. Some = of the deliverables may be published through the IETF RFC stream as = informational or standards track documents. - CACAO Use Cases and Requirements - Specify the use cases and requirements - CACAO Functional Architecture: Roles and Interfaces - Specify the system functions and roles that are needed to enable = Collaborative Courses of Action - CACAO Protocol Specification - Specify and standardize the configuration for at least one protocol = that can be used to distribute courses of action in both a direct = delivery and publish-subscribe method - CACAO Distribution and Response Application Layer Protocol - Identify and document the requirements to effectively report and = alert on the deployment of CACAO actions and the potential threat = response to those actions - CACAO JSON Data Model - Create a JSON data model that can capture and enable collaborative = courses of action - CACAO Interoperability Test Documents - Define and create a series of tests and documents to assist with = interoperability of the various systems involved.=20 The working group may decide to not publish the use cases and = requirements and test documents as RFCs. That decision will be made = during the lifetime of the working group.=20 ### END Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." --Apple-Mail=_3B63EF84-822B-434D-A971-1428D09DAFB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

Thanks for all of the great feedback on the charter text. =  We have updated the document to address all comments that we have = received and are releasing a new version of the text.  You can see = it here: https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ and copied below.



# Introduction

To defend against threat actors and their tactics, = techniques, and procedures, organizations need to manually identify, = create, and document prevention, mitigation, and remediation steps. = These steps when grouped together into a course of action (COA) / = playbook are used to protect systems, networks, data, and users. The = problem is, once these steps have been created there is no standardized = and structured way to document them, verify they were correctly = executed, or easily share them across organizational boundaries and = technology stacks.

This = working group will create a standard that implements the playbook model = based on current industry best practices for cybersecurity. =

This = solution will specifically enable:

1. the creation and documentation of COAs in a = structured machine-readable format
2. = organizations to perform attestations on COAs
3. the sharing and distribution of COAs across = organizational boundaries and technology stacks
4. the verification of deployed COAs. =

This solution will contain (at a minimum) a = standard JSON based data model, a defined set of functional capabilities = and associated interfaces, and a mandatory to implement protocol. This = solution will also provide a data model for actuators to confirm the = status of the COA execution, however, it will be agnostic of how the COA = is implemented by the actuator.

Each collaborative course of action will consist = of a sequence of cyber defense actions that can be executed by the = various systems that can act on those actions. Further, these COAs will = be coordinated and deployed across heterogeneous cyber security systems = such that both the actions requested and the resultant outcomes may be = verified. These COA actions will be referenceable in a connected data = structure like the OASIS STIX V2 model that provides support for = connected data such as threat actors, campaigns, intrusion sets, = malware, attack patterns, and other adversarial techniques, tactics, and = procedures (TTPs).

Where = possible the working group will consider existing efforts, like OASIS = OpenC2 and IETF I2NSF that define the atomic actions to be included in a = process or sequence. The working group will not consider how shared = actions are used/enforced, except where a response is expected for a = specific action or step.

# Goals and = Deliverables

This = working group has the following major goals and deliverables. Some of = the deliverables may be published through the IETF RFC stream as = informational or standards track documents.

- CACAO = Use Cases and Requirements
=   - Specify the use cases and requirements
- CACAO Functional Architecture: Roles and = Interfaces
=   - Specify the system functions and roles that are needed to = enable Collaborative Courses of Action
- CACAO Protocol Specification
  - Specify and standardize the = configuration for at least one protocol that can be used to distribute = courses of action in both a direct delivery and publish-subscribe = method
- CACAO = Distribution and Response Application Layer Protocol
  - Identify and document the = requirements to effectively report and alert on the deployment of CACAO = actions and the potential threat response to those = actions
- CACAO = JSON Data Model
=   - Create a JSON data model that can capture and enable = collaborative courses of action
- CACAO = Interoperability Test Documents
=   - Define and create a series of tests and documents to = assist with interoperability of the various systems involved. =

The working = group may decide to not publish the use cases and requirements and test = documents as RFCs. That decision will be made during the lifetime of the = working group.




Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."

= --Apple-Mail=_3B63EF84-822B-434D-A971-1428D09DAFB1--