From nobody Fri Feb 2 06:20:35 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8450112D86F for ; Fri, 2 Feb 2018 06:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 X_zyVoLOGBRq for ; Fri, 2 Feb 2018 06:20:31 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A3A4B12D863 for ; Fri, 2 Feb 2018 06:20:31 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w12EHMu9003303 for ; Fri, 2 Feb 2018 14:20:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=DqPbMDJWySxXdPxXFypiKeKFOFyQeyCJ7+LvDk+sKY4=; b=QaM9KrrCO0A6FsxSBE2mVtHFR/ZSMXdD0quKXpsT93LE/x8gtjl9+12xJLNH/pVCOJ7m a9MLsMHiLUufDqeUsP9v49fAiaRr269raTTPc8lTz4r/SCFrUDWl4id8TXmSX39szvaA LwEU3XZMw56S9G8fbCANYIwk2bMuC9HX6E/vizKT4MIHZV9JieLXI7A8noMsxWvJi41K YNONxBBLvD+/sZojLFkaUS28gks2odpjWdpwPKOPga8VYIBQR44MGxFPnwh89+jLxONR mnjoly7nahv/iPMtzor23U2LERIiCSGmgXQSCNTXBcbIE85aqcgAiTSCqOA5dBYVMLvy Hw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2fv5ydu9ag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 02 Feb 2018 14:20:29 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w12EG2Hf015456 for ; Fri, 2 Feb 2018 09:20:28 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2frnmyeqrg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 02 Feb 2018 09:20:28 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Feb 2018 09:20:27 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 2 Feb 2018 09:20:27 -0500 From: "Salz, Rich" To: saag Thread-Topic: [Cryptography] NSA's 5th annual Science of Security paper award Thread-Index: AQHTmx0hPShaH1vddEaDJkGsGJzLi6ORf4iA Date: Fri, 2 Feb 2018 14:20:27 +0000 Message-ID: <0BA3B7CD-6BA2-4307-A53A-6A77ADAC1C7B@akamai.com> References: <20180201035653.33E6EA06E74@palinka.tinho.net> In-Reply-To: <20180201035653.33E6EA06E74@palinka.tinho.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-02_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=991 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802020177 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-02_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=937 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802020177 Archived-At: Subject: [saag] FW: [Cryptography] NSA's 5th annual Science of Security paper award X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 14:20:34 -0000 RllJDQoNCk9uIDIvMS8xOCwgMTI6MjUgQU0sICJkYW5AZ2Vlci5vcmciIDxkYW5AZ2Vlci5vcmc+ IHdyb3RlOg0KDQogICAgSGVsbG8uICBJIGFtIHdyaXRpbmcgdG8gaGVscCByZWNydWl0IG5vbWlu YXRpb25zIGZvciBOU0EncyA1dGgNCiAgICBBbm51YWwgQmVzdCBTY2llbmNlIG9mIEN5YmVyc2Vj dXJpdHkgcGFwZXIgYXdhcmQsIHdoaWNoIGNvdmVycw0KICAgIHBhcGVycyBwdWJsaXNoZWQgaW4g Y2FsZW5kYXIgMjAxNy4gIE5vbWluYXRpb25zIGNsb3NlIGF0IHRoZSBlbmQNCiAgICBvZiBuZXh0 IG1vbnRoLCBNYXJjaCwgMjAxOC4NCiAgICANCiAgICBUaGUgZXhlcmNpc2Ugb2YgdHJ5aW5nIHRv IGlkZW50aWZ5IHdoYXQgcGFwZXIgcHJvdmlkZWQgdGhlIHN0cm9uZ2VzdA0KICAgICpzY2llbnRp ZmljKiBjb250cmlidXRpb24gdG8gdGhlIGZpZWxkIGluIHRoZSBwYXN0IGNhbGVuZGFyIHllYXIN CiAgICBwcm92aWRlcyBhbiBpbnRlcmVzdGluZyBwZXJzcGVjdGl2ZSBmcm9tIHdoaWNoIHRvIHJl dmlldyByZWNlbnRseQ0KICAgIHB1Ymxpc2hlZCB3b3JrIGFuZCBhc3Nlc3MgaXRzIHNpZ25pZmlj YW5jZS4gIEkgaG9wZSB5b3UnbGwgdGFrZQ0KICAgIGFkdmFudGFnZSBvZiB0aGlzIGludml0YXRp b24gdG8gZG8ganVzdCB0aGF0Lg0KICAgIA0KICAgIE5vbWluYXRlZCBwYXBlcnMgYXJlIHJldmll d2VkIGJ5IGEgc2V0IG9mIG5hbWVkIGV4cGVydHMsIHdpdGggdGhlDQogICAgZmluYWwgc2VsZWN0 aW9uIG1hZGUgYnkgTlNBJ3MgRGlyZWN0b3Igb2YgUmVzZWFyY2gsIERyLiBEZWIgRnJpbmNrZS4N CiAgICBUaGUgbGlzdCBvZiByZXZpZXdlcnMgYW5kIGFsbCBvdGhlciBkZXRhaWxzIG9uIHRoZSBj b21wZXRpdGlvbiBjYW4NCiAgICBiZSBmb3VuZCBoZXJlOg0KICAgIA0KICAgICAgaHR0cDovL2Nw cy12by5vcmcvZ3JvdXAvc29zL3BhcGVyY29tcGV0aXRpb24NCiAgICANCiAgICBQYXN0IHdpbm5p bmcgcGFwZXJzIGFyZSBsaXN0ZWQgaGVyZToNCiAgICANCiAgICAgIGh0dHA6Ly9jcHMtdm8ub3Jn L2dyb3VwL3Nvcy9wYXBlcmNvbXBldGl0aW9uL3Bhc3Rjb21wZXRpdGlvbnMNCiAgICANCiAgICBB bmQsIG1vc3QgaW1wb3J0YW50LCB0aGUgcGxhY2UgdG8gc3VibWl0IG5vbWluYXRpb25zIGlzIGhl cmU6DQogICAgDQogICAgICBodHRwOi8vY3BzLXZvLm9yZy9ncm91cC9zb3MvcGFwZXJjb21wZXRp dGlvbi9zdWJtaXQNCiAgICANCiAgICANCiAgICAtLWRhbg0KICAgIA0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgVGhlIGNyeXB0b2dyYXBo eSBtYWlsaW5nIGxpc3QNCiAgICBjcnlwdG9ncmFwaHlAbWV0emRvd2QuY29tDQogICAgaHR0cDov L3d3dy5tZXR6ZG93ZC5jb20vbWFpbG1hbi9saXN0aW5mby9jcnlwdG9ncmFwaHkNCg0K From nobody Mon Feb 5 06:24:50 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DDB12D7F1 for ; Mon, 5 Feb 2018 06:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 ePFo9RYHfFq8 for ; Mon, 5 Feb 2018 06:24:45 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 4BF661242F7 for ; Mon, 5 Feb 2018 06:24:45 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id l5so20905518otj.11 for ; Mon, 05 Feb 2018 06:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XnzV+sR+4Tjj2AO5PZUhW3dCjj4eVvNds/Po3Zeidt0=; b=aaocH3k/8aS5INFZONmDuN8gk9AY6+Q8rPxQkL1cwll1gShe09j2Xr1IeqI7/zHi7P iTkCEeTzTJ+BiX5QnfakAmEPBZsG10o676gqDeyLpOK4BVUH/1YXf1eZvlhScdwleEov FYvbA5pRqji0924kZkWmqGUKRH4UeEq5DQRnv3tmM9Fw+KbyQxhUyNlsvJ9WF2SXsgT4 mzbBxLq4P0HHEGNZ21y8R2UZnuhHBI5sFXj0V7hd6zoyvLbf7YowhlqXzcbmCHhzfldu rE4o5S2M1AisvVYHsO9mzjJTOJj6VBkYWzIbgGcu69h2s6Ug+paEzKloNazkVdAIL8Z4 sAGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XnzV+sR+4Tjj2AO5PZUhW3dCjj4eVvNds/Po3Zeidt0=; b=HkQpHAvBluY3vNOolKKoleB2QvxVvQ3JKvw00alUZFDakpYoXXdI3PfgYtTRwqdNR3 h9Y9NKETZCi2ss9R3woh2K2nse1lVdm98vTprb9rOqZWceHZu85DuSVEhKlGp4/WT/d7 wi+gquzFBoOW9kXjkcD7qKYFJP7FUNlo5DWn2kWAjhSfFXQLkIJJUh2hSUMrZcjskH/l /At9ZXjeXwQVprscZHoypZAjMk9U4UCIIYEswn21Yg2sUFZNgR2uBz2CpZBX7GZGZC94 sHGRI+HIzYLaJmznlbEjXWL8XMyVzs6z/bf+xin/mvg6crC4yazwjqPzFRDQoAWRn/FN TAKw== X-Gm-Message-State: AKwxytflVtqO/B8ZfSVGAcfAXswGeoGV7EDsw7iTDY0PrdEWaVqaqvhL /jgqI+/ucJN7QccMg44P34D7HrcgUrIuN/BSgs3xaSN3CBU= X-Google-Smtp-Source: AH8x227VJH1o8Uku1goUErLLWe7WY5F+y0Fb7gzxXIeHWWZxms/nhwVRS/K2vTUp97YJVtHsR5HLmCF4OSnQHGqiJKw= X-Received: by 10.157.59.8 with SMTP id z8mr8333766otb.45.1517840684329; Mon, 05 Feb 2018 06:24:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Mon, 5 Feb 2018 06:24:03 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> From: Yakov Shafranovich Date: Mon, 5 Feb 2018 09:24:03 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 14:24:48 -0000 Also, Google now publishes a security.txt file for their domain here: https://www.google.com/.well-known/security.txt There are also some tools for various platforms being developed by community members here: https://securitytxt.org/projects Thanks On Tue, Jan 2, 2018 at 7:01 PM, Yakov Shafranovich wrote: > FYI > > ---------- Forwarded message ---------- > From: > Date: Wed, Dec 27, 2017 at 11:38 AM > Subject: New Version Notification for draft-foudil-securitytxt-02.txt > To: Edwin Foudil , Yakov Shafranovich > > > > > A new version of I-D, draft-foudil-securitytxt-02.txt > has been successfully submitted by Edwin Foudil and posted to the > IETF repository. > > Name: draft-foudil-securitytxt > Revision: 02 > Title: A Method for Web Security Policies > Document date: 2017-12-27 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-02.txt > Status: https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ > Htmlized: https://tools.ietf.org/html/draft-foudil-securitytxt-02 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-02 > > Abstract: > When security risks in web services are discovered by independent > security researchers who understand the severity of the risk, they > often lack the channels to properly disclose them. As a result, > security issues may be left unreported. security.txt defines a > standard to help organizations define the process for security > researchers to securely disclose security vulnerabilities. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Mon Feb 5 13:12:33 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9E612DA02 for ; Mon, 5 Feb 2018 13:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 9bTm86Mp47t7 for ; Mon, 5 Feb 2018 13:12:30 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2E0AA12D9FE for ; Mon, 5 Feb 2018 13:12:30 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w15LCRjd024867; Mon, 5 Feb 2018 21:12:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=uCrgRjUJyJy6qdlBpziTApn4SP1vdpuDCMnjtU/PElA=; b=H7pyp1wmdNjhSjlDzPQQ2TlMo6kigp9HiTiOkPOLD1XvxyHfljodjhSuv4pHJTurA2f/ NdGhUUfh1snnixDmS9Mqaf7EJVrF3c1mArrVbfre4Dhl1R+fQlAB27AzOjtO3FRiqsCc evo0Vfcumouwjv2R25/dOQCkXSyn4QgWR4Ucj/14xKxo9+eFOoTARqzJOXZRid9ueijF Hr5SvMashUvDBDIA9KWBF25MDfzGpTmNzyPeEbzy9L4OpjXVhIMxTGzpw0mg121hRIpo A7UAH4mu80yypTuYFVHibfUWyepYG0ZOooStAHNcY14netqA7mXVnfo99V9tptg5pUyy 6A== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2fw5g68mgd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 21:12:28 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w15LBUKP018709; Mon, 5 Feb 2018 16:12:27 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fw9a0wnee-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 16:12:27 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Feb 2018 16:12:25 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 5 Feb 2018 16:12:25 -0500 From: "Salz, Rich" To: Yakov Shafranovich , "saag@ietf.org" Thread-Topic: [saag] New Version Notification for draft-foudil-securitytxt-02.txt Thread-Index: AQHTno0YQ/zmuRL1906ONjdVNg9FvKOWosGA Date: Mon, 5 Feb 2018 21:12:25 +0000 Message-ID: <98C9A08F-8A1A-4D67-A1FE-6787EF1730DC@akamai.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.233] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=534 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050261 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=481 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050261 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 21:12:33 -0000 4p6iIEFsc28sIEdvb2dsZSBub3cgcHVibGlzaGVzIGEgc2VjdXJpdHkudHh0IGZpbGUgZm9yIHRo ZWlyIGRvbWFpbiBoZXJlOg0KICAgIGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vLndlbGwta25vd24v c2VjdXJpdHkudHh0DQogICAgDQpPcGVuU1NMIGlzIGFsc28gZG9pbmcgaXQsIGFzIGFuIGV4cGVy aW1lbnQuICBodHRwczovL3d3dy5vcGVuc3NsLm9yZy8ud2VsbF9rbm93bi9zZWN1cml0eS50eHQN Cg0KDQo= From nobody Mon Feb 5 16:54:13 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21E12DA17 for ; Mon, 5 Feb 2018 16:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 nd_2t7tiPNvn for ; Mon, 5 Feb 2018 16:54:10 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 80E0F126C26 for ; Mon, 5 Feb 2018 16:54:10 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id a2so212821otf.2 for ; Mon, 05 Feb 2018 16:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=DpfUFRhVZO7l2qPkLM9/K/yoKsngIkxJul3iMVENk88=; b=xzXb1rlTJqg3QMYlNnMdEcQkuCeclDS8BwJ3kOwnnAfD+UEp0xaJTaDiX/MRrxhEOz lvtU/jkghid6N75fwoPmT/a372epvN6TFA+k8S/gEX/ZDNgYOptb4C+2Auptkreit1KP BgZeUT0PnRbSuI2AtkVtXCmvyGrh16+QweKfbAf657XoY9ov3BbQt2tQlcR9RKnn4PAu wPhraDQbXICYtXqa1sEBPEZ0gErW894U0Bszj07nEfH484zuZq1oUeBgCh8sVn8DtFX5 XGB1GqqCr7kRyNJwhgjak0rQ+bMn/qBqgJrg5082u+203Jvx9/Etw4VMPSM2UZSWFyLh TDcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DpfUFRhVZO7l2qPkLM9/K/yoKsngIkxJul3iMVENk88=; b=IpMNECuMh9ue47CdjRFWZ4D7jJNL58Ff1kbmDyRRFFy30OsLdoEWOPpCxdMsb4k+vf 3IYw4ftBlAroOB9dhUgOlGOBl6qTn4YNrp1EEiIEfYol262z21T5ZXoRFPzqLL2iswro aFtk0V4S9V/CY0Nx18NcUFzPdXgjO+ZbALaC5/5WW+v7Nz02m6mA7HJtkplaZTr3Gihd gx9h5WnKwW0mN7WM+rL2F8j5L2r3oj82zFG22W4RVXRv+fHgpT17TvHgJWDU5Snx+tzM Sno0vugxAFB+lBaiS1/er5EqLDzKZ+jsco4Cri4gOvT6Xg4uRzPjjBTZCXVSuekGw5Vz Wvqg== X-Gm-Message-State: APf1xPCQXQQ2cpmtdsxMGz2HbsQ6D1q4uGXGmUFvoc6ieBFvRlcHmXY2 Z6tra4IYMFpXZqtl7r28gv+tM3dMbTJKEDXwmOGYsdJstP8= X-Google-Smtp-Source: AH8x226kwvPr+LYTJh1IuFJGJJ07EcS3/+xYoGrGWOD9xBhLjLs10aMzJjUe9zwqwEdCzdXtkuN6XwqS6f4SrgfGwqo= X-Received: by 10.157.21.87 with SMTP id z23mr437500otz.365.1517878449709; Mon, 05 Feb 2018 16:54:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Mon, 5 Feb 2018 16:53:29 -0800 (PST) From: Yakov Shafranovich Date: Mon, 5 Feb 2018 19:53:29 -0500 Message-ID: To: saag@ietf.org Cc: Ed Overflow Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 00:54:12 -0000 (This is related to this draft: https://tools.ietf.org/html/draft-foudil-securitytxt-02) The proposed "security.txt" file has a matching optional "security.txt.sig" file. One of the common issues we have received as a feedback from potential users is a need to safeguard against the possibility of an attacker compromising the webspace of a given domain, and putting their own "security.txt" and "security.txt.sig" files there. This will result in an attacker now receiving reports about potential security issues in the compromised target. One of the proposed ways to try to fix this issue is to use DNS as follows: - to store the digital certificate that was used to generate the signature file - OR to store the signature itself in DNS - OR to store the entire "security.txt" file in a DNS record instead of being accessible via the web The logic behind this proposed solution is that web space tends to get compromised more often and easier than DNS for any given domain. What I am wondering if there are any currently best accepted practices to accomplish these goals in DNS with minimum disruption to the Internet architecture as whole. Possibilities I was thinking of is using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT records like DKIM and SPF. Any recommendations, suggestions or comments are welcome. Thank you, Yakov From nobody Mon Feb 5 16:59:54 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF82E12DA17 for ; Mon, 5 Feb 2018 16:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 6TiibTwO7jTr for ; Mon, 5 Feb 2018 16:59:50 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 7016D126C26 for ; Mon, 5 Feb 2018 16:59:50 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id e15so167777oiy.2 for ; Mon, 05 Feb 2018 16:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9yC4ZDdOZp6V+r3OyeTwIz/fKEnBJwB3lunqo/yN8RE=; b=a/jdw1+GOII6p9q2BiquufWIsK86HZBteiCGMBb1uhvQkEE1Me0oQarOZnZd/tWDGt 9PqpnmUTtm4iJ8Ps5lSeoQWE2CIIM/HzQNLhhcehZMMSWlY9qtw+WNhUYbijnKXRHv0a Zej/Pbq+x2jZf+KANuNhQYsMlqPbKsX4h3llkCZGYreAGgJom6ZZPxjV7zeGNYUl6noq DBJ2jM5edWuuLUoLFZDCK6UaYPiAcDOCjWRmh62UW7Ae/UXkTyQex72RmrMbC/xsIxw7 L2jk09wK8jqRT4QklKo2xXAxhRFJ3trNqpzml6HkiVCsW3v8WzpFVgeePaiuPijOKDbD 6iAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9yC4ZDdOZp6V+r3OyeTwIz/fKEnBJwB3lunqo/yN8RE=; b=ukiTG8aIImbV1/MHT+HocjAs4bF2s4Op0HgcEyTQXPlnVZnda/JKVM3thPH7OBQlA/ GI1elq8mly8GUo9wRstVsei2uC1pkY+k0phFS4N88/RLq/+5uJ7mmDK1MVsZD6OsBTPL G0Gaz0ASWJVh/TkXZ5Op1d2/RlMNAwaRa2rpnNDbxly4zL8VfQEeYwRx4QeGFOruSO1T Kndg0Lx9tF0hRmticTNRYRYyy3GlLjzjgc3YJh+yqdMPtPdliIh4WJ1dv8uS2cawFisR AMjdcWXGfLHmsJdOyxP5J6tIf4+vwJipbqAdQ1zASsN/qlNzEt9TBqnFOAEW0ebNoVpc qyJg== X-Gm-Message-State: APf1xPDrF1EQVOfPTqUW6Qme0eAOaYvdXRJfpCM6Ypzk/AtLDOC6kQoR JOfqAC5uTdBeM7I7BEy5ipJ5K5KlqvaIPUMqnLvIhw== X-Google-Smtp-Source: AH8x227z32vXadZ1Mz8kg/VtTWQYs3oSyKkpDzbjSHbvZAts97jNn0hg52tT0FhSY3e+WehT29NRuxw/HsAE9GoOi/8= X-Received: by 10.202.23.9 with SMTP id j9mr441305oii.50.1517878789716; Mon, 05 Feb 2018 16:59:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Mon, 5 Feb 2018 16:59:49 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 6 Feb 2018 11:59:49 +1100 Message-ID: To: Yakov Shafranovich Cc: saag , Ed Overflow Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 00:59:53 -0000 Have you considered formatting the signature as a certificate and submitting it to a CT log? That gives you an audit capability. BTW, I noticed that the draft says SHOULD for HTTPS, which is a much bigger hole than this. On Tue, Feb 6, 2018 at 11:53 AM, Yakov Shafranovich wrote: > (This is related to this draft: > https://tools.ietf.org/html/draft-foudil-securitytxt-02) > > The proposed "security.txt" file has a matching optional > "security.txt.sig" file. One of the common issues we have received as > a feedback from potential users is a need to safeguard against the > possibility of an attacker compromising the webspace of a given > domain, and putting their own "security.txt" and "security.txt.sig" > files there. This will result in an attacker now receiving reports > about potential security issues in the compromised target. > > One of the proposed ways to try to fix this issue is to use DNS as follows: > - to store the digital certificate that was used to generate the signature file > - OR to store the signature itself in DNS > - OR to store the entire "security.txt" file in a DNS record instead > of being accessible via the web > > The logic behind this proposed solution is that web space tends to get > compromised more often and easier than DNS for any given domain. > > What I am wondering if there are any currently best accepted practices > to accomplish these goals in DNS with minimum disruption to the > Internet architecture as whole. Possibilities I was thinking of is > using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT > records like DKIM and SPF. > > Any recommendations, suggestions or comments are welcome. > > Thank you, > Yakov > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Feb 6 06:46:21 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AA612D7EC for ; Tue, 6 Feb 2018 06:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hT7gHJvbqIBk for ; Tue, 6 Feb 2018 06:46:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9440712426E for ; Tue, 6 Feb 2018 06:46:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ej4Vk-000438-R7; Tue, 06 Feb 2018 14:46:17 +0000 Date: Tue, 06 Feb 2018 23:46:14 +0900 Message-ID: From: Randy Bush To: Yakov Shafranovich Cc: Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 14:46:20 -0000 for fun, and because it seemed trivial, i hacked up a security.txt for https://rg.net/.well-known/security.txt the document has issues (he said trying to learn californian). e.g. 2.5. Signature: In order to ensure the authenticty of the security.txt file one SHOULD use the "Signature:" directive, which allows you to link to an external signature. External signature files should be named "security.txt.sig" and also be placed under the /.well-known/ path. External signature files SHOULD be loaded over HTTPS. Here is an example of an external signature file. Signature: https://example.com/.well-known/security.txt.sig that is not "an example of an external signature file" at all. it is an example of a Signature: line in a security.txt file. in fact, there is no definition of a signature file or what it contains other than this hint. To ensure the authenticity of the security.txt file, organizations SHOULD sign the file and include the signature using the "Signature:" directive. so i guessed and `gpg --clear-signed` the security.txt file with the pgp key referenced by the "Encryption:" line, producing security.txt.sig (although the convention would name it .asc). but i have no belief that this ensures the authenticity of anything. randy From nobody Tue Feb 6 13:53:29 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4D112D95C for ; Tue, 6 Feb 2018 13:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 bm9bDxqejUb9 for ; Tue, 6 Feb 2018 13:53:26 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 E0B0512D955 for ; Tue, 6 Feb 2018 13:53:25 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id x21so2492748oie.13 for ; Tue, 06 Feb 2018 13:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v9roNBqGNmHtJoXW6DGbgvO76hv1iIAsRSSUrJipBCc=; b=PBb017t2I2tsmOSg5jwbQ2esJmBY7pHZQOiqzJi/jkxqR2czDS42BtqzhaupZ17Fi1 dJN8CRJrbk8RVIkQZm+B2s76rMaFO58WWqtH2t8ZebvmTxNSZNyb5eGMBpEzWXldD7bv iyz7+sqef9jnFcXvpFLWt6b8FWIacrb9XAiD303UkqgC2+030IYdJVXAbcRSzotIwyY6 7oHDDROfB9bgzovEavI4i2NSFdMS+STl8EtmcZHYzkxkBWDw99oSYpKSrp0IoUtzpwAl S72vEE7CoTJmXZnjjZtuqRhJp2KxuPkLIhmfofnToN8gPzWocsJlygygwR2BwLuCmeJA RSYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v9roNBqGNmHtJoXW6DGbgvO76hv1iIAsRSSUrJipBCc=; b=abRS0n4+aJTUkGqiyCVLsoWEn4ye7YO3Z3hN0d6IsHKkB2KgjE2e+JJAIk8Mb4qUub upFTVem018XVNUHHOW4qDPOyjZAPAMxIp6kWU/vvRHLQ9qFhW9G4ly5n9ngSDJhkfn8z 8nHWqF33uEuS5jqW8fzu3voQBTKBkLYt8RRgWp+g4tuDAbZE/+4Qfo9qKLS3tBz6xD4Y JgSA9G1BkMWaAa2EPNrrELmF2D/RjOvJt1k5k+4N5OmYPFCPo4DWaiq/JEDaweMQVCcf ZR2sNRYtUguG1EISgQbX13lt5H4Xlcg2+Z8wvuUWmoKCND7lLvMuQBdGVsP43KPlWVe0 UVbg== X-Gm-Message-State: APf1xPC6xoU5XNSlxMBnMrVQpLMSlwQ/GDZyV26eNlsAlTGxubWg/bem l6E+VW93yj65zPBwl7hXGsfLZjE+9ndTvaMXAtdlBA== X-Google-Smtp-Source: AH8x225bwL4X4fxYeoUJax+/LHieH8vH3YueHHLe1zLvs7xu13YJcLKok+vVVeemIMKkjjhaeWcdvCmAtqZ8Us8V6fw= X-Received: by 10.202.44.149 with SMTP id s143mr2429045ois.212.1517954005088; Tue, 06 Feb 2018 13:53:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Tue, 6 Feb 2018 13:52:44 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> From: Yakov Shafranovich Date: Tue, 6 Feb 2018 16:52:44 -0500 Message-ID: To: Randy Bush Cc: Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 21:53:28 -0000 Hi Randy, That is kind of what prompted my earlier question to the list regarding DNS here: https://www.ietf.org/mail-archive/web/saag/current/msg08098.html For the signature, one proposal bouncing around so far has been to have the signature inline, the other proposal which is in the draft is to have a second signature file placed next to the file. As you have highlighted, in both cases there is no definition of what type of signature it actually is. I don't have a problem standardizing on PGP signatures but that would kind of lock the proposal to PGP only and I was hoping to something more extensible. The obvious bigger problem is that no matter where the signature is placed (inline or separately), how do we make sure that the signature is legit? If an attacker can compromise the webspace, then presumingly they can compromise the signature as well. One proposed solution has been to ties the authentication of the signature to the domain where the "security.txt" file is actually placed, and then rely on the fact that it is harder to compromise DNS vs. the web. Empirical evidence suggests that may be true but I am not entirely sure. Another possibility is to tie it to the domain via a CA-issued certificate, thus relying on the CA verification. However, with LetsEncrypt and ACME. the webspace (i.e. "well-known" directory) is used for verification as well, so that puts us back at square one. Regarding the encryption header, that is the key meant to be used for encrypting communication between the reporter and the receiving entity: 2.4. Encryption: This directive allows you to add your key for encrypted communication. You MUST NOT directly add your key. The value MUST be a link to a page which contains your key. Keys SHOULD be loaded over HTTPS. Thanks On Tue, Feb 6, 2018 at 9:46 AM, Randy Bush wrote: > for fun, and because it seemed trivial, i hacked up a security.txt for > https://rg.net/.well-known/security.txt > > the document has issues (he said trying to learn californian). e.g. > > 2.5. Signature: > > In order to ensure the authenticty of the security.txt file one > SHOULD use the "Signature:" directive, which allows you to link to an > external signature. External signature files should be named > "security.txt.sig" and also be placed under the /.well-known/ path. > External signature files SHOULD be loaded over HTTPS. > > Here is an example of an external signature file. > > Signature: https://example.com/.well-known/security.txt.sig > > that is not "an example of an external signature file" at all. it is an > example of a Signature: line in a security.txt file. in fact, there is > no definition of a signature file or what it contains other than this > hint. > > To ensure the authenticity of the security.txt file, organizations > SHOULD sign the file and include the signature using the "Signature:" > directive. > > so i guessed and `gpg --clear-signed` the security.txt file with the pgp > key referenced by the "Encryption:" line, producing security.txt.sig > (although the convention would name it .asc). but i have no belief that > this ensures the authenticity of anything. > > randy From nobody Tue Feb 6 14:39:27 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9943412D882 for ; Tue, 6 Feb 2018 14:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 eEYv5OaicSDY for ; Tue, 6 Feb 2018 14:39:24 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 2ACA212711E for ; Tue, 6 Feb 2018 14:39:24 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id e15so2597763oiy.2 for ; Tue, 06 Feb 2018 14:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Brp1yjvehiJSCmx9IV7EgDyjDlSWZXa5W/dkHPOcM+U=; b=pk7tU5L8uU3iIJNnC8UFLoZ2mwgTDtp8olNpyvQ1Yy9/x7+/YyX3EhYuSVN1ADQqm5 +r8T8t2Z6mLygLkhbwn75P2LfKGluFK+tdQ0NqOELysUa1rY0JuaENUBWuh216IpKbzw vcWvG2Xex9n2aLGUf9MjPv6cvI8NbeVuKYIQx6dOVfvYoCQZ/JCzvrPhbo/346hwieL7 NYdCgPIIiCDSjaAYwmeH3eh71dHeP2fzE9CjG5wluAVQnWrimUuUYhNBJme84iuKAJMO HlNQRnaTP0/esTASx0mWO+TizcR0Mj7Yf1SmDGtu1GbiwhDe7S3UmBPznwf9s5r/ZJ+t xFbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Brp1yjvehiJSCmx9IV7EgDyjDlSWZXa5W/dkHPOcM+U=; b=byJl29IEiI0ondT3ym74YnlFZb9c21A7+pI02n9bN5PhB35r3ORY5nZJ4dJh8Cm9we qi/k2AIvoMyA6N2C7AT7wO+Ool4Pt2tisYY1+0CFL1CzQ+L1EFGldXKnb/TdeYa2gc7G 8O+0bxL5v6HL9KdN2WqzjW93HYsIx0hwcf83fmHUTDMlQeygoefYj9Hfb5TuQ1ORjSxT rIRnhw6QpvsmD6TUnlojDw30eZothvT7fxFD1nYa41T9QIeUe6mvSxn6+3AtV1SETddL S4qdKoWig/cIK7qZ/09gDFPANI4S047bMf52D2DbGFn8PxAVBY3gy+7ch0T3ahJeAKCU ZmGA== X-Gm-Message-State: APf1xPBUsQ2OjEJxtIHH9L1lqnz/JANleFkgk1dvmcFPfUIK6g6oFgVG De7G9RWbnRpNCU/Sa0smLaG0MxqYmlymI6utR/5RIg== X-Google-Smtp-Source: AH8x225ZvXci9dt0onF19sSaxMQxed+92y3P1syFD+RnfOgrKMeXYL24iiuSj0iknnFGKT5VxBQwze3EkO7igqiUO9U= X-Received: by 10.202.173.11 with SMTP id w11mr2606542oie.299.1517956763400; Tue, 06 Feb 2018 14:39:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Tue, 6 Feb 2018 14:38:43 -0800 (PST) In-Reply-To: References: From: Yakov Shafranovich Date: Tue, 6 Feb 2018 17:38:43 -0500 Message-ID: To: Martin Thomson Cc: saag , Ed Overflow Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 22:39:26 -0000 Hi Martin, Thank you for the suggestion. Is there anyone today using the CT logs system for tracking things other than certificate issuance? Also, there is a question around ease of use. I was thinking that the level of effort for an administrator to set this up should be about the same as the level of effort required for setting up CAA, SPF, DMARC or DKIM which involves setting up some DNS records. How easy would it be to pull this off? I also added an issue to track the HTTPS language here: https://github.com/securitytxt/security-txt/issues/94 Yakov On Mon, Feb 5, 2018 at 7:59 PM, Martin Thomson wrote: > Have you considered formatting the signature as a certificate and > submitting it to a CT log? That gives you an audit capability. > > BTW, I noticed that the draft says SHOULD for HTTPS, which is a much > bigger hole than this. > > On Tue, Feb 6, 2018 at 11:53 AM, Yakov Shafranovich > wrote: >> (This is related to this draft: >> https://tools.ietf.org/html/draft-foudil-securitytxt-02) >> >> The proposed "security.txt" file has a matching optional >> "security.txt.sig" file. One of the common issues we have received as >> a feedback from potential users is a need to safeguard against the >> possibility of an attacker compromising the webspace of a given >> domain, and putting their own "security.txt" and "security.txt.sig" >> files there. This will result in an attacker now receiving reports >> about potential security issues in the compromised target. >> >> One of the proposed ways to try to fix this issue is to use DNS as follows: >> - to store the digital certificate that was used to generate the signature file >> - OR to store the signature itself in DNS >> - OR to store the entire "security.txt" file in a DNS record instead >> of being accessible via the web >> >> The logic behind this proposed solution is that web space tends to get >> compromised more often and easier than DNS for any given domain. >> >> What I am wondering if there are any currently best accepted practices >> to accomplish these goals in DNS with minimum disruption to the >> Internet architecture as whole. Possibilities I was thinking of is >> using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT >> records like DKIM and SPF. >> >> Any recommendations, suggestions or comments are welcome. >> >> Thank you, >> Yakov >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag From nobody Tue Feb 6 14:59:39 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0865C12DA1A for ; Tue, 6 Feb 2018 14:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 ru_NTKpV8Sgo for ; Tue, 6 Feb 2018 14:59:36 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 09A0312DA0C for ; Tue, 6 Feb 2018 14:59:36 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id j15so2629620oii.5 for ; Tue, 06 Feb 2018 14:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k1DghGfOPjbM0PXQPzATw+32waq+v6WqOl3nKaLwiwg=; b=ackAdQJ1UxC1fR5LswLEW0y5bmUUeWaPqZ7euOGplDrGl1bRMj6RO6VN24Opq2ckWL HGls+bJKTZybORMcqOnLlRS6c4ctZ1xI3BLjzRNIjezvTNz6Nz7N9AH+93/ipweqab9P MRh2FNikPHFuCMw+Q6/3dcYwPAEQ1Aiu+0BhzCcpSIIk52ZJ9VJFD1STGOpBFKJ8WfkC iufhbN1MhwEHBd2ADZbjLVY4D4f/VurFgvXxzx6uYU2ccdAhpz7MWJjmHlRy9T5FPfUU RF4N//0HOrd6tiDD4U2Pw2CCSuBjZ8xs8KHEjYlFsUMlLxDD3LYVrlvtDgXzLJusCezR dYyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k1DghGfOPjbM0PXQPzATw+32waq+v6WqOl3nKaLwiwg=; b=nrsVdSYHAbuwWeBnHko5ubbemu+fxJqE3IgGZiu86dSNHBzR2YToiJNwFWrbScjXdm 0eXwqPR3pzhQ8p3ujU0L9foBwAFxrVOLnkwxb72RFOiy95u9VbKIP83r9sDEOP3V/OvC NRl1w6HSAdslJ78rAQdOVm0P91Q/bPU3NYuOCzem36e3FSO8r0g/SWu14l6SFhuMlPGg YG6QulZWHKoo6p5rgs/z280ryDNi2wkLq4+RyajHr+nwVthhQMrwKeyjf/ItOYJRvaqw bUE5nOGzDfeUcPAx2sC+fh4WZblcbgQHfX5IAO87ya4oXUzQUgsidDgQ5etSD53ck9V6 1qTw== X-Gm-Message-State: APf1xPCfKcSzsdQkurzbUk5sFp3LnOg8D2lGrQFHUz1Yl8NufUQISiAi 9hMNgxVGJ4uzT5qUE7jPp3YJAOglZxA83Nj9XXsfEAk+ X-Google-Smtp-Source: AH8x226YBZ+AUkRSEhVP2lKNIhT61wD7b1dWydIsnSbapxh4s9dI9YmAlEDBcQTBMUfiPR2XaK0VzqQXmYjvKg5ZaXc= X-Received: by 10.202.217.2 with SMTP id q2mr2714894oig.28.1517957975309; Tue, 06 Feb 2018 14:59:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Tue, 6 Feb 2018 14:59:34 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 7 Feb 2018 09:59:34 +1100 Message-ID: To: Yakov Shafranovich Cc: saag , Ed Overflow Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 22:59:38 -0000 On Wed, Feb 7, 2018 at 9:38 AM, Yakov Shafranovich wrote: > Thank you for the suggestion. Is there anyone today using the CT logs > system for tracking things other than certificate issuance? https://wiki.mozilla.org/Security/Binary_Transparency I believe that some people were not happy that this was even being considered, so exercise caution. > Also, there is a question around ease of use. I was thinking that the > level of effort for an administrator to set this up should be about > the same as the level of effort required for setting up CAA, SPF, > DMARC or DKIM which involves setting up some DNS records. How easy > would it be to pull this off? Ease of use is relative here. You are talking about creating a separate key and publishing that using a wholly different channel. For the specifics, you would have to ask someone with more CT experience than I. From nobody Tue Feb 6 15:48:10 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B265126DFB for ; Tue, 6 Feb 2018 15:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 cnGtcKchxmoq for ; Tue, 6 Feb 2018 15:48:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08545126DCA for ; Tue, 6 Feb 2018 15:48:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88F54BE5F; Tue, 6 Feb 2018 23:48:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtPVIpi6f4H1; Tue, 6 Feb 2018 23:48:00 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A7C5BE51; Tue, 6 Feb 2018 23:48:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517960880; bh=RGOn1JSJHS1Dq4ArKNBGuEcTMygfYuAkkq82lR2oVi0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=N4NaWE4fFFBxMeFwfZ109dEKdyuWiedF8Yd1LFf/ZqWGY2ryooweqh2WkBbjD8ORM KglUoZj7jk+rfQSzFsplXPf9xMUmleGatqwWX7xEiQHPw7zS7rqvFS8jII72G7OS1m 91bn0oFYd7yfxQrMH5AabUjYdwkcZ3J3hRAVbukk= To: Yakov Shafranovich , Randy Bush Cc: Security Area Advisory Group References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> Date: Tue, 6 Feb 2018 23:47:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PhZawXaXeP9oN7oYoMI46Ef5RPsLfg6Ci" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 23:48:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PhZawXaXeP9oN7oYoMI46Ef5RPsLfg6Ci Content-Type: multipart/mixed; boundary="Swurji1ytiZVMUF4Y57VK9S5auwOuoVo3"; protected-headers="v1" From: Stephen Farrell To: Yakov Shafranovich , Randy Bush Cc: Security Area Advisory Group Message-ID: <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> In-Reply-To: --Swurji1ytiZVMUF4Y57VK9S5auwOuoVo3 Content-Type: multipart/mixed; boundary="------------A9F2AC6405DBE6E2FE22D0AD" Content-Language: en-GB This is a multi-part message in MIME format. --------------A9F2AC6405DBE6E2FE22D0AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 06/02/18 21:52, Yakov Shafranovich wrote: > The obvious bigger problem is that no matter where the signature is > placed (inline or separately), how do we make sure that the signature > is legit?=20 I don't have a solution, but one thought is that if I wanted to report something to the contact point, and if the current security.txt file has changed since I last looked, perhaps I ought use both the last-but-one and the current value. (The current value being at risk of being attacker-controlled.) So, yes, append-only logs (like CT) may have a role here. One ickky hack idea might be to map the desired content of security.txt into certbot/openssl command line options that end up in the CSR, then shoot that at LE using the HTTP challenge type (easy enough since one is assumed to control =2Ewell-known) then log the resulting bastardised cert into the current CT logs. You'd also want to figure a way that a potential reporter could easily spot the right values via crt.sh I suppose. And all of the above could still use a security.txt file, you'd just also include the command(s) used as well:-) Renewal could be tricky given the LE 90 day lifetime. But one could have a fun argument that expiry is no big deal in this case. (Send your reporting email to all of 'em.) The above would of course also require one to hold one's nose for at least the time it takes to type the command:-) And of course all of that just adds up to "put an email in the cert for your domain" and "encourage folks to send issues to that email." S. PS: I like the idea of something like this - the above might read as if I don't. But I do:-) --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------A9F2AC6405DBE6E2FE22D0AD Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------A9F2AC6405DBE6E2FE22D0AD-- --Swurji1ytiZVMUF4Y57VK9S5auwOuoVo3-- --PhZawXaXeP9oN7oYoMI46Ef5RPsLfg6Ci Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaej6vAAoJEFqy+vF7Fyvq9rUP/Rtq5e1rahbukrWiWTIZADLo WhTDkZYY3e4A2kOYsZCSICWT4WEyFxtcBTlyYzy3v31HavbPFdkSlUhjdEO0zI9W Y7fKHsijfhZw/31Lz8SZSSPkfIQB8bVIboPfUBXXX7lDd2CO3gbkoj4w2Ui7sHbH Ui+uxwvK+Tbx/qKyTRgez7OAtqcJZ6azIQw4yDRXl754igbZ37nsSOg5y3Vjq/8S /LVpYabpJrlbFK8lppNs2xRKd9utncY7m+tYarGdKKQOHLwKaFe9SRpBRJpkY8p2 VkCJSlBb/WReuDuHGrRoOY+kyJ0vGrosIHgBhLWM/QzQn1PjjQIdLE6g+Hqx1+dt Ap5wRN+lqvFdyDuuPoqwSVJLms7//Exo4O+dsWX1b9XjvoF9uJ0jZb5AKLR78TsX GvWwUI8pNaR3oicVjT2e/2me8PAMfnCD9sz3YxZwdAvStdc2eEKwzWfY2iJFMrj7 16K2Z/V8TjvvmqOo3YDEZOL9VL6GTBPEdBgHPsG6VooK7taUXuBudh9TRYCidu6l cD/mOx5uyxsgGUU36z8tjChWMGDy9g42Si1BhJnCurfvpdfL8QOnzhQWhLVbkM6N yonaqE4g/ZeOqYGhRNfy9nhJ/ESkN3zxnQRVoUj6dxroRyZZzAvH4W0UnddDqsz6 KF7qcIwbgi/1eVsFd5Gn =BhOe -----END PGP SIGNATURE----- --PhZawXaXeP9oN7oYoMI46Ef5RPsLfg6Ci-- From nobody Tue Feb 6 17:31:23 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA5C1242EA for ; Tue, 6 Feb 2018 17:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 9P8dQpp-z9ft for ; Tue, 6 Feb 2018 17:31:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 62AB4124B18 for ; Tue, 6 Feb 2018 17:31:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejEZt-0001h6-Bz; Wed, 07 Feb 2018 01:31:13 +0000 Date: Wed, 07 Feb 2018 10:31:12 +0900 Message-ID: From: Randy Bush To: Stephen Farrell Cc: Yakov Shafranovich , Security Area Advisory Group In-Reply-To: <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:31:22 -0000 > PS: I like the idea of something like this - the above might > read as if I don't. But I do:-) same. but it is not well thought out and not usefully prototyped. if the signed security.txt.sig contains security.txt, who the heck needs security.txt? and emacs is easier to use than the web site; ok, vi for the younger folk. i suspect that pretty much anyone who would do this knows how to use a text editor. for the moment, have the sha256 of the signed blob in a TXT record and provide a validating tool; your zone is signed, isn't it. the web site could do validation for the lazy instead of being a completely gooeyfied text editor; just pass it the url. if you want sig flexibility, put it in the file name, security.pgp security.smime whatever keep it simple randy From nobody Tue Feb 6 17:37:42 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1FC129C53 for ; Tue, 6 Feb 2018 17:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 fN-M8NCZWxgW for ; Tue, 6 Feb 2018 17:37:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 581B81242EA for ; Tue, 6 Feb 2018 17:37:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejEg4-0001kt-Va; Wed, 07 Feb 2018 01:37:37 +0000 Date: Wed, 07 Feb 2018 10:37:36 +0900 Message-ID: From: Randy Bush To: Stephen Farrell Cc: Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:37:42 -0000 % cat security.txt.sig -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Contact: mailto:randy@rg.net Contact: mailto:randy@psg.com Contact: +1 206 356-8341 Encryption: https://archive.psg.com/pgp-key.txt Signature: https://rg.net/.well-known/security.txt.sig -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCgAdFiEEvg4r8bKCC0+Upw9l1Vl2leo342AFAlp5vDgACgkQ1Vl2leo3 42Dvjg//XYpmw0m18mZ1it5GUYcydumVSEHQfgTyF8k96mM7Gkc3A9tFuP+plQyM /VWOMlY4i+gulwj+nRrEX+kvFXUlrg9/AJblgx24wxc/RugGt7XUT0cvfycPAuxf C6hc0W7Pl7uYLOAW9KOFMyQSP9hE3p6eqs3zoTf/cUG4qlchZ9rVQ4tmV5ftaUmT q5LTXHJ/hcquw90solXgu4BWohQSNHbxrONZML6DCCwQsN41L8hq1OokbORwTYIZ hNve4+ueuPa9NpvQc8JBk98BHa6KRejDCxxbXeWYFr5kYxMJf+tp5pQKM2u/I35X jNRJIByg9V9F7Lyc8NOPbQMDrbv5jj3U+x1LOniwHOBLX5KvexdAL1c20CdPBcUE wNO7jU5BpmTueowvH9RyyP6ZhkcLDLDkF1EK3rXvmr6kRo5zGElZou0vQ8j91ZTw 1c2mn4m74NoDsA0O7JC9SrCDBvNSQNntoNr+DR06z5apg6gw5VDbkA2/L5K0vvyg rUGANdvXRaqWltCXWEmXZsfKCJkx0pD+TWiC0Bg0EKPB5d7kmbGtAyTGFCLNplaw LhiQhk2h0X0kSu8SHmLPU9rM9+rEOxm0wlk5VX0WshvTDTLe+x6nrCp6zTCJh6oj JykM6brzvfntxVjONxEkce0mB4ffm/LkK9wMHUwgjrR5TMQF9Z8= =ag3A -----END PGP SIGNATURE----- % sha256 security.txt.sig SHA256 (security.txt.sig) = fa1dce4207c0087d19d949bb600613fff2bcd2933e76749afedcb8e5500e70a9 % dig +short security.txt.sig.rg.net. txt "fa1dce4207c0087d19d949bb600613fff2bcd2933e76749afedcb8e5500e70a9" From nobody Tue Feb 6 17:44:51 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75197124B18 for ; Tue, 6 Feb 2018 17:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 n89I2vS5OUIY for ; Tue, 6 Feb 2018 17:44:48 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 BFCFC1242EA for ; Tue, 6 Feb 2018 17:44:48 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id m20so3701858otf.3 for ; Tue, 06 Feb 2018 17:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9Vn3WLFiP5/xzikYAZdquRdl8h1sOjFKoBopS+/fX0E=; b=iXMN0C/kZWZtXYkcrW+QhpsUEycha6r337h8g6XpjzuH1afsJkkrQvr4TLW4O406ek pnY8DSOl8eJ8wdEpz+ZWz8cGaicAgSqRwQFeD4Yxw8VO7TStitbF6tuuvoPPnh8p0QrU KFgmgsofXLuVYCR9jAN131KaWuoQZ6u5aTCXGiA/gUEICvVGGxoh0UMnEgY9zaQLBpYr 7m3Kb/emQUfnjIrwzbvy3+PzQkMpUSTUpVxGE28joePR9auJGNkGVxh2Er+pTIuT1sns pyIg5UuRFlN/1teCoSxq3DltnUkAfFwK2HqRpiiR1ghqInpbW3JZKUaZFO8y2vZuqG8H AJ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Vn3WLFiP5/xzikYAZdquRdl8h1sOjFKoBopS+/fX0E=; b=D2Pmev9CYXm9+g0BfT34FbgWLlozq44OIz5V/qfRlvP9WQGAqTM7l6n4psUiLzNZ3h WYA23Ip+PHde6AJ9UoYo52up0PWzTRb9yJXBY9m4sNlvfTNGihBtW1drJFW+q0IM1Z7x KtSFlHuWaMpSesU3SfrgP2fAr/LVqq4vYEwSkdkpsfhLTk6e1GT82iWElmP1gHA7TeVf pQt7zpRIRY2BNJxwLAbqpQLcRtNrDEtcWQumq64tRN8gDY8rV9W1+ff2OjJFYiQKH01H n8CU6F9ukSSDlQcWZ41PBsjq3FrzUG4DU/1S9CSOyJSWNCshYBT0A9xeKzWyrYspouir 5yTQ== X-Gm-Message-State: APf1xPAauOOvwiAw4mZ48GVlkWIflU+Diebdi7mf83bZqf/c+MEvqnqv 7+iyY9xN83iyM6ZKBQfpgVIWqjUjqK0IBcAGqCBwPQ== X-Google-Smtp-Source: AH8x227BZlXqXqW+AKDOm1pLIFuZmPKwHWDMvVlZXpeh0IDxAud9qR1Onrw3t5FWq6gqYMYR+bWz0ao4gnv6noQOfu4= X-Received: by 10.157.21.87 with SMTP id z23mr3117912otz.365.1517967887640; Tue, 06 Feb 2018 17:44:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Tue, 6 Feb 2018 17:44:07 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> From: Yakov Shafranovich Date: Tue, 6 Feb 2018 20:44:07 -0500 Message-ID: To: Randy Bush Cc: Stephen Farrell , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:44:50 -0000 On Tue, Feb 6, 2018 at 8:31 PM, Randy Bush wrote: > > for the moment, have the sha256 of the signed blob in a TXT record and > provide a validating tool; your zone is signed, isn't it. the web site > could do validation for the lazy instead of being a completely gooeyfied > text editor; just pass it the url. > Here is also an example of specifying a signature with URIs: Signature: dns:security.txt.sig.rg.net?type=TXT From nobody Tue Feb 6 17:46:57 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9BD129C53 for ; Tue, 6 Feb 2018 17:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 tEBBp7C6wyIp for ; Tue, 6 Feb 2018 17:46:54 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 536511242EA for ; Tue, 6 Feb 2018 17:46:54 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejEp1-0001n9-Mm; Wed, 07 Feb 2018 01:46:51 +0000 Date: Wed, 07 Feb 2018 10:46:50 +0900 Message-ID: From: Randy Bush To: Yakov Shafranovich Cc: Stephen Farrell , Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:46:55 -0000 > Here is also an example of specifying a signature with URIs: > > Signature: dns:security.txt.sig.rg.net?type=TXT this is an example of no actual authentication. we leave why it fails as an exercise for the student. randy From nobody Tue Feb 6 17:55:14 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9D12D0C3 for ; Tue, 6 Feb 2018 17:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 68CPOZ1lqYFK for ; Tue, 6 Feb 2018 17:55:11 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 DD3D11242EA for ; Tue, 6 Feb 2018 17:55:10 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id l8so2891964oig.0 for ; Tue, 06 Feb 2018 17:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WkpIAAsWAc9Z5G8YVQGvZdWZUeokvs929M5PnvRq5qM=; b=VCc4xW9p35nALwWfcYvtL7YwUNBXZEl6yzmP73to1B0WnS9bWNA60UYXeGqhEHb+IR gJqemifwVVKUW4ET2eYY8LcHhhN10mjsUZMu7w9JxV+UMN5z3BlJW6EMbRZbdh7oQqYo 62mUrweQh1GRr/GwyYdH7g7FIsOgT3BB58bbRN8QNkXRDYQR1SacgsMM9HXKd6P1VP+e OS2GsCXGrNW76zaBULWtWhP9w8RL59JDXcgaARWGiWeQOkTkfuAvaXgD+2cHadFIZluE 3UvKbzvIZB79RtnqMioaks8TX7yBZCvYRQmMv4eVyNt0hhI7tu2EulO4A9vYyfj+3UX6 iqyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WkpIAAsWAc9Z5G8YVQGvZdWZUeokvs929M5PnvRq5qM=; b=ldGUzL5+eMW0XcVVNXKxG0io0YRdjnmV0rJE2mWZEOnOHtRBbxdv5jUFdnlmWefhkm /NrHJa+RNcIe7jorAhVHImeQP90D2hCE5mb5mcpXE26uxCdzcKWO5+NTOTHOsPp3Lqdd EuVQcRt1l8LmvkVcRFYRpU39lxqQ9EQBQFNVK9cyCS28eOidL5lAFT6m1WM4F0KT+gqp c/YANA6BQXWWMSQzR7ei8nKuDbzlNT0m/nbS6ctbBWjqjUKvA9wxkfk6pFhqsD6pbCHV 9lbII2kRx5klu18fk8UsAPYqofx14cBHRvMVx9z87wMC4gLYd5+TRcvjL9bS115tzsi3 di4w== X-Gm-Message-State: APf1xPDcppfQldRln0RK1xtAUXR88hiL4CayipMAMx7VUc+R3Y0VyUiO qu0bFqQseo436/WHYCVUzeM7Oi2czBhXHke0Rp9rRg== X-Google-Smtp-Source: AH8x226+mrKvPlyRzwsVekraRSXUf/GdzE1y2flVEi1g1IXGjbQfY1UJmEEF7VxIqLqQZh5qu3D6qDY+ERhl8IG7JdA= X-Received: by 10.202.208.145 with SMTP id j17mr2885584oiy.95.1517968510180; Tue, 06 Feb 2018 17:55:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Tue, 6 Feb 2018 17:54:29 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> From: Yakov Shafranovich Date: Tue, 6 Feb 2018 20:54:29 -0500 Message-ID: To: Randy Bush Cc: Stephen Farrell , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:55:12 -0000 On Tue, Feb 6, 2018 at 8:31 PM, Randy Bush wrote: > > if the signed security.txt.sig contains security.txt, who the heck needs > security.txt? and emacs is easier to use than the web site; ok, vi for > the younger folk. i suspect that pretty much anyone who would do this > knows how to use a text editor. > > for the moment, have the sha256 of the signed blob in a TXT record and > provide a validating tool; your zone is signed, isn't it. the web site > could do validation for the lazy instead of being a completely gooeyfied > text editor; just pass it the url. > Puts the signature with the content, avoids the separate signature file and provides DNS validation. Any preference on where in DNS should the validation be placed? Thanks From nobody Tue Feb 6 18:06:20 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212C812D0C3 for ; Tue, 6 Feb 2018 18:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 YdlXFOkrnLiR for ; Tue, 6 Feb 2018 18:06:16 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9E0C012421A for ; Tue, 6 Feb 2018 18:06:16 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1722siF014496; Wed, 7 Feb 2018 02:06:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=l0zDM98QVzLM+kP38sdFLZlIZ074ltovc1BCa1X0ZFk=; b=KhcYSRsf0CBYa195S8LTfBXBIDYMQYen7BvBULy9AahqSHZo/Nw13iJMUSYswanSvMw8 7N+0JhZSakJxNiJAPy7eqTivK1j/u6R5OLIC83JTqdrkNoF9jIwK99opjKgb+tNwqkhL wROakRm2Ayjf+B/bXV1HY781vumdIMT64PrdqTB2iIbSZzzeoI2sn3HKzob4Q/7p/vUv V8GRhcT05gizthKt+2seLcNxRdljENYKB6tGePs70AJ2MLhh+M4RXRyPNQhXesSFebkM f+EO6wDqgJgio2o8mTb/IfOwY2v7y1I0tPFx7sMSK71qgJw8N0WKjNBVG3LSUhWDIJm8 QA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2fw57s5awy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 02:06:16 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1726FeJ021666; Tue, 6 Feb 2018 21:06:15 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fw9a11b1v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Feb 2018 21:06:15 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 6 Feb 2018 21:06:13 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 6 Feb 2018 21:06:13 -0500 From: "Salz, Rich" To: Yakov Shafranovich , Randy Bush CC: Security Area Advisory Group Thread-Topic: [saag] New Version Notification for draft-foudil-securitytxt-02.txt Thread-Index: AQHTno0YQ/zmuRL1906ONjdVNg9FvKOXyTAAgAB3KgCAACAzgIAAHNcAgAAGgYCAAANGAA== Date: Wed, 7 Feb 2018 02:06:13 +0000 Message-ID: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.12] Content-Type: text/plain; charset="utf-8" Content-ID: <576ED2519141D040AD5CC7E34A15CB28@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=719 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070022 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=658 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070021 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 02:06:18 -0000 4p6iIEFueSBwcmVmZXJlbmNlIG9uIHdoZXJlIGluIEROUyBzaG91bGQgdGhlIHZhbGlkYXRpb24g YmUgcGxhY2VkPw0KICAgIA0KVGhlcmUgYXJlbuKAmXQgbWFueSBwbGFjZXMgb3Igd2F5cyB0byBw dXQgaW5mb3JtYXRpb24gaW50byBETlMuICBBbmQgdGhlbiB5b3XigJl2ZSBzd2FwcGVkIHNlbGYt Y2VydGlmaWNhdGlvbiBmb3IgdHJ1c3RpbmcgYW4gaW5zZWN1cmUgc3lzdGVtLCBubz8NCg0K From nobody Tue Feb 6 18:13:17 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A4D12D859 for ; Tue, 6 Feb 2018 18:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 YmnkM3tPi7rT for ; Tue, 6 Feb 2018 18:13:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7660412421A for ; Tue, 6 Feb 2018 18:13:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejFES-0001t1-N2; Wed, 07 Feb 2018 02:13:08 +0000 Date: Wed, 07 Feb 2018 11:13:07 +0900 Message-ID: From: Randy Bush To: Rich Salz Cc: Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 02:13:15 -0000 > =E2=9E=A2 Any preference on where in DNS should the validation be placed? at the node over which the sec info is asserting authority. see my simple example. > There aren=E2=80=99t many places or ways to put information into DNS. And > then you=E2=80=99ve swapped self-certification for trusting an insecure > system, no? you don't run dnssec? you're kidding, right? randy From nobody Tue Feb 6 18:19:32 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F5412D859 for ; Tue, 6 Feb 2018 18:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 kZcGMIHQL7ft for ; Tue, 6 Feb 2018 18:19:30 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B495F12421A for ; Tue, 6 Feb 2018 18:19:30 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1726gwV023282; Wed, 7 Feb 2018 02:19:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Du3FPcrxwukofAXF7xi14cLBpWJxZgGfZeMyBVUK9bs=; b=dFwuSbhE6JtEHEy6jDJVw7qCsKpZvqUQJeV1M/Vfq/fG4OXBMRuesgn6vLn335u+jDSp zfzIVz9IJ4IfrxUGyuw9B+dYmSUFZMKDm+g6G7UG3AOjzb4dobGe2JeFfisWTTrZ7Mdp dNN2qr6GTRRdZm1heV/7h7BwQxuyznyrSfs+0IOoyMoEt1mzwgwrkj0QvjNN3YrMLdpn y4HRqpjB8R2QQxajeqWxlU6WqAtnq4e7FE2PTFuLqBu4nRx6Z2mwAXJ/4TIDw/vUte1i lF+DB483GH2ZSYaJOeBuJwfrs6nKdOr40tSW5XRKos7RySJevKvzW7yVt1Y9ky3gGPaa dQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2fw31guxx4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 02:19:27 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1726CHf009789; Tue, 6 Feb 2018 21:19:25 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fw9a03wcf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Feb 2018 21:19:25 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 6 Feb 2018 21:19:24 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 6 Feb 2018 21:19:24 -0500 From: "Salz, Rich" To: Randy Bush CC: Security Area Advisory Group Thread-Topic: [saag] New Version Notification for draft-foudil-securitytxt-02.txt Thread-Index: AQHTno0YQ/zmuRL1906ONjdVNg9FvKOXyTAAgAB3KgCAACAzgIAAHNcAgAAGgYCAAANGAIAAAe+AgAABwIA= Date: Wed, 7 Feb 2018 02:19:24 +0000 Message-ID: <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.12] Content-Type: text/plain; charset="utf-8" Content-ID: <0A6F469E9A70CD4F95E67AAF837A5010@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=579 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070022 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=521 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070022 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 02:19:32 -0000 4p6iIHlvdSBkb24ndCBydW4gZG5zc2VjPyAgeW91J3JlIGtpZGRpbmcsIHJpZ2h0Pw0KICAgIA0K Tm8gY29tbWVudCBvbiBETlNTRUMuICBJIGRvbuKAmXQgcnVuIGFueSBETlMuICBBbmQgSSB0aGlu ayB3ZSB3YW50IHRoaXMgdG8gYmUgbW9yZSB3aWRlbHkgdXNlZCB0aGFuIEROU1NFQyBkZXBsb3lt ZW50LiAgQW0gSSBtaXN0YWtlbj8gOikNCg0K From nobody Tue Feb 6 18:27:04 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A681912421A for ; Tue, 6 Feb 2018 18:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 Lo9PrVNHrzZO for ; Tue, 6 Feb 2018 18:27:02 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 243091204DA for ; Tue, 6 Feb 2018 18:27:02 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id m20so3776077otf.3 for ; Tue, 06 Feb 2018 18:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XXjd6mFxc6N8Pfrcr02v2FxtJskoRjj8WDVAR/AeJ4g=; b=mrXWd4ARuldhp/kgxZs0ovcmobpGTy1LmxUA/6vmQGzbtaoV2BsPYL/tExFCqzbpgo 39lmX+9BHLlxLM2KskbUVNoT9r9fZxSzZfws8nfUf02FvW0VL34nTk2H5EqQCESJ8dhW JBbbs5HFlGz+9mS1jCOSYU7xVA6AZFFIUL2xiZbx2M0Ly10uxzJI3CEn4ldq/qcvyAPl Dt7oPjodn50djoMXeIyfjhQcbD8N0HB/0g6+kzebRsiIs7kxXVWrzAGCkY/V5aMbRD+I 4DhwJ/qm9e7NdulS7+c5k65TEi28iYs4RVDehzgPMB7RaizvK37IMTTLZFGdpnidoTHq zEKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XXjd6mFxc6N8Pfrcr02v2FxtJskoRjj8WDVAR/AeJ4g=; b=iaGrGz/ctvBXCQCgV8AlungpBzSIKV7QdnG/UFZ9xgtxZ1+sPa5CWRThPQFP7n4bW+ 8X9gb6Z7HAhRCormWu8gXx2pKKjyxrSbfoFV54idJZ5IlFuf3Gn9DRNxYWSIGFefvaas uIR/aPQqlOH6a4d59EXhNsOxshOENqQBhX+XF8vqlILuOEZK3ZnXZU7UBb7c2LW+FVTS E9yTNW2Smb48lrO2C6IJ6bak5eA2DzoYwarcaW3p3k9eqglrLcufLQnZjlMdhyX+Ho0w tRboSWwDyUiBfA70oNpya2GKDTXLkcM6GKhZbOBKd+ySSDj5CPpnM4oio98kHPID2fZl EakA== X-Gm-Message-State: APf1xPBz0gmUwY4thl1EGzYjcXfNy3oDELUpwVSrfH8+o3MhWguY2MWA kum8bbVW3MlIYi4SpsTgRzPAsTl6Mo5aTfJisCyRUA== X-Google-Smtp-Source: AH8x227WOx2UmXnfefW/Wapd1oXnAcKezn5x/gPkMuai2+/ZmwY5sbXrmUAewhk9OgeUR/KaFRM7UwwOWP6t2qtr88c= X-Received: by 10.157.2.167 with SMTP id 36mr3065416otl.23.1517970421362; Tue, 06 Feb 2018 18:27:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Tue, 6 Feb 2018 18:26:21 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> From: Yakov Shafranovich Date: Tue, 6 Feb 2018 21:26:21 -0500 Message-ID: To: Randy Bush Cc: Rich Salz , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 02:27:04 -0000 On Tue, Feb 6, 2018 at 9:13 PM, Randy Bush wrote: >> =E2=9E=A2 Any preference on where in DNS should the validation be placed= ? > > at the node over which the sec info is asserting authority. see my > simple example. > I did see the example. My question is really around whether there specific guidance for subdomains like these in DNS? For example, DMARC (RFC 7489, section 6.1) usually puts its records as TXT in the "_dmarc.example.com" subdomains. DKIM (RFC 6376, section 3.6.2.1) uses "_domainkey.example.com" subdomains for public keys. SPF (RFC 7208, section 3) on the other hand puts stuff in a TXT record for the apex domain, and doesn't use subdomains. I also remember back when I was involved with SPF et al, the use of TXT records was frowned upon, although that seems to have changed. Thanks From nobody Tue Feb 6 18:52:14 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677F112DA13 for ; Tue, 6 Feb 2018 18:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 Xc8d12gUcjF3 for ; Tue, 6 Feb 2018 18:52:12 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 0A7A2120725 for ; Tue, 6 Feb 2018 18:52:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejFqE-0002AC-5a; Wed, 07 Feb 2018 02:52:10 +0000 Date: Wed, 07 Feb 2018 11:52:08 +0900 Message-ID: From: Randy Bush To: "Salz, Rich" Cc: Security Area Advisory Group In-Reply-To: <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 02:52:13 -0000 > =E2=9E=A2 you don't run dnssec? you're kidding, right? > =20 > No comment on DNSSEC. I don=E2=80=99t run any DNS. And I think we want = this > to be more widely used than DNSSEC deployment. Am I mistaken? :) you want an authenticated second authority. dns, blockchain, ct, ... take your pick. dns was simplest for my hack. From nobody Tue Feb 6 19:23:29 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE41C12D877 for ; Tue, 6 Feb 2018 19:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 0JYXQUyDF9Xg for ; Tue, 6 Feb 2018 19:23:26 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 44820120725 for ; Tue, 6 Feb 2018 19:23:26 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id 24so3005051oij.3 for ; Tue, 06 Feb 2018 19:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5HhdxWaNy69WsI009kfUG2+XLSvWCfQT6LEJG8bLxiQ=; b=sli9+wQTpu3tGNuv8vRah/+vTVbmxTM3oTakJgRkVC7PidydGI1Izilhf2+/lu0LVa ULoNRPzBWWiXQIMYjRber7f2AR2xCXy0BqklnxQlqqYRqKGjzmq6RrutJ1yzwGIcpeOL lGIXZgXNFTL/9hND+i5/F6bvyNoxClE6ZB2Ypn451OmV8CAVvNkwRYNfVAcrk5LiHhhu BsdgfLLs+e4ALjRtxoWvmqInxxCJkiaeRIT/w2h5RthUhEkjz7ugSHgJ5HMAet1zrzph tikJfG8yxwYTHewcX3mNGu8vGe59iXTXLJdXdczPUOn/WvvF5Q5wJxngM3ObQXHT4iRs Tptw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5HhdxWaNy69WsI009kfUG2+XLSvWCfQT6LEJG8bLxiQ=; b=GfzDdSQH+rbYeEeCUKxpMIkggfRp1L390goE4lxVpxi4QIGf2G7Gax7+e6u/XXKs2J kpU6khG/Akxdaw9pMGohHLSLTCQDXE1TEsB64vkEF8Mf14jlp1TZngrhbSDiMg/716I6 7bPc9n5tpNMUSV+SOepcsT5X13H8UuMzUwoOnETTmP9JHayWgVr2c7YNlXGwyPyOQu4+ xAbqW6lfO6U08TUe4R9/kl79WW3HfynUZzcQfvf5S3/fUyO43dmrsbCvWS+6YLhtbpB4 g63OzUMmgYI8hnMbgG4xVctYPEymRh4IfBcfibeZOPuv4kRkeOxbr4q8LxHwt/qU5ALe p27g== X-Gm-Message-State: APf1xPAN/4bu1R5yzARFNEtwxChb4kOJmUuL4zmuLKhq+bWCzVgUIBZG +GWrmuxEG9T9CHwclFgvM010NagntCOA3aNSpK8o0g== X-Google-Smtp-Source: AH8x225caesUyij5BgHSd8ajfg2QxUB09+ITigefrYR2bZ5hTeaeChxjNx6DnO4iF1S/8O5r3sgIBudKBgjJDGepcrI= X-Received: by 10.202.173.11 with SMTP id w11mr3012115oie.299.1517973805586; Tue, 06 Feb 2018 19:23:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Tue, 6 Feb 2018 19:22:45 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> From: Yakov Shafranovich Date: Tue, 6 Feb 2018 22:22:45 -0500 Message-ID: To: Randy Bush Cc: Rich Salz , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 03:23:28 -0000 And my other question is regarding the hash itself, is there an easy way to specify the hash function name because SHA-256 will be deprecated someday. I couldn't find a standard way to specify an algorithm and a hash, the closest thing is NI, which seems clunky: "ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q" On Tue, Feb 6, 2018 at 9:26 PM, Yakov Shafranovich wrote: > On Tue, Feb 6, 2018 at 9:13 PM, Randy Bush wrote: >>> =E2=9E=A2 Any preference on where in DNS should the validation be place= d? >> >> at the node over which the sec info is asserting authority. see my >> simple example. >> > > I did see the example. My question is really around whether there > specific guidance for subdomains like these in DNS? For example, DMARC > (RFC 7489, section 6.1) usually puts its records as TXT in the > "_dmarc.example.com" subdomains. DKIM (RFC 6376, section 3.6.2.1) uses > "_domainkey.example.com" subdomains for public keys. SPF (RFC 7208, > section 3) on the other hand puts stuff in a TXT record for the apex > domain, and doesn't use subdomains. > > I also remember back when I was involved with SPF et al, the use of > TXT records was frowned upon, although that seems to have changed. > > Thanks From nobody Wed Feb 7 01:04:30 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DF8126BF0 for ; Wed, 7 Feb 2018 01:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 lruQ8R6Vc5YL for ; Wed, 7 Feb 2018 01:04:28 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 17B231200C1 for ; Wed, 7 Feb 2018 01:04:28 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ejLeT-0001l9-Rq; Wed, 07 Feb 2018 10:04:26 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=[193.0.22.9]) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ejLeT-0001lt-N5; Wed, 07 Feb 2018 10:04:25 +0100 To: Yakov Shafranovich References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> Cc: saag From: Robert Kisteleki Organization: RIPE NCC Message-ID: <47e4b4ef-1042-a702-ca01-fee7fab5a867@ripe.net> Date: Wed, 7 Feb 2018 10:04:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2743b1d37ea44c0385c9387abb0f3784298 Archived-At: Subject: [saag] (was: Fwd: New Version Notification for draft-foudil-securitytxt-02.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 09:04:29 -0000 Hi, The document states (in 1.1 Motivation) that the goal is to make the document machine-parsable. However, when describing the format for Contact: lines in 2.3, it allows using email addresses to be included "without a prefix for ease of use and readability" (it's a SHOULD, not a MUST). Ease of use and [human] readability is not real concern is the intention is to be read by machines. On the other hand, the above flexibility will lead to the need to use regular expressions (or such) to find and parse the actual email address if one wants to implement automatic notifications to such addresses. So I feel that this flexibility is actually a drawback -- I believe the draft should mandate "proper" syntax. As an alternative, one could split the contact lines into contact-web, contact-phone, contact-email, contact-postal, ... IRR style entries instead. Regards, Robert From nobody Wed Feb 7 01:36:33 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F26126CC7 for ; Wed, 7 Feb 2018 01:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 lhXRpG3DgBMT for ; Wed, 7 Feb 2018 01:36:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A136D126BF0 for ; Wed, 7 Feb 2018 01:36:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37956BE4C; Wed, 7 Feb 2018 09:36:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfE9MehIjSjn; Wed, 7 Feb 2018 09:36:24 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2488FBE49; Wed, 7 Feb 2018 09:36:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517996184; bh=9wHtxi0hnh4N8HQOFJg4z3sW5P7VhKf542uAlkZGnn0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NiCbdZVyk8keVIzngLF+Y6pQxM267v+I/yF6z8/2mQQKeHYPlfErFF03RdR8IQYKJ 3oGDg3JbeudsevAkD4azT55CKGwYge2Z+T4qfJN4ro1KjFyim5ZB3zops5YPu6CgQJ ZSuIQtNgSuTVvbR9Qx62W75bMSTYo2shyIpXcnUY= To: Randy Bush , "Salz, Rich" Cc: Security Area Advisory Group References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Wed, 7 Feb 2018 09:36:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BNIEDwiH4xIm1P1gfMCe5UG4Vt8Dluf1t" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 09:36:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BNIEDwiH4xIm1P1gfMCe5UG4Vt8Dluf1t Content-Type: multipart/mixed; boundary="deg68Qxec67b1sCFGLbaATEUJLmjRS6HO"; protected-headers="v1" From: Stephen Farrell To: Randy Bush , "Salz, Rich" Cc: Security Area Advisory Group Message-ID: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> In-Reply-To: --deg68Qxec67b1sCFGLbaATEUJLmjRS6HO Content-Type: multipart/mixed; boundary="------------EC3494FB883C10482D8C6070" Content-Language: en-GB This is a multi-part message in MIME format. --------------EC3494FB883C10482D8C6070 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/02/18 02:52, Randy Bush wrote: >> =E2=9E=A2 you don't run dnssec? you're kidding, right? >> =20 >> No comment on DNSSEC. I don=E2=80=99t run any DNS. And I think we wa= nt this >> to be more widely used than DNSSEC deployment. Am I mistaken? :) >=20 > you want an authenticated second authority. dns, blockchain, ct, ... > take your pick. dns was simplest for my hack. Randy is correct - another party is needed in this case for the signature to be worth anything. In addition, you do also want some memory of previous values, as in the event of this being useful you can't necessarily believe the current values. So while a DNSSEC'd RR of some sort could validate the hash, without passive DNS, you'd not get the history, so you'd be vulnerable to anyone who can re-write the web site and the RR - though that's still way better than just the web site in a lot of cases. For me, that maybe means CT and the X.509 cert for the domain is worth a look, so I might actually try a certbot/openssl CLI hack to see if I can get the contact info into the cert in a usable manner. (I already did publish [1] but I've not yet verified the signature myself even, so it's just for fun so far:-) And in case folks aren't familiar with how that makes history visible, [2] shows the certs I've had for that domain. The downside of looking at CT of course is that it's more likely an attacker could get a new cert from LE for the domain if they control the web site than it is that the same attacker could get a new RR published. So a certbot/openssl approach probably makes the current value less trustworthy than a DNS based approach. The historical values are still good though and the change could in itself be a useful signal. On the third hand, DNSSEC is still rare (it is setup for jell.ie), so we'd want to think out the DNS-without-DNSSEC cases too. I think DNS still offers an additional difficulty for an attacker in that case, for many web sites, so a DKIM-like approach that doesn't require DNSSEC could also be considered even if it's strictly less good than one that has DNSSEC. Lastly, as another off-the-wall idea, archive.org could be a third party for this if the URL ends up is crawlable. That's probably not really dependable enough though. Cheers, S. PS: It might be a few days before I get to play with the certbot/openssl approach mentioned above. [1] https://jell.ie/.well-known/security.txt [2] https://crt.sh/?q=3Djell.ie >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------EC3494FB883C10482D8C6070 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------EC3494FB883C10482D8C6070-- --deg68Qxec67b1sCFGLbaATEUJLmjRS6HO-- --BNIEDwiH4xIm1P1gfMCe5UG4Vt8Dluf1t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaesiXAAoJEFqy+vF7FyvqBKEQAI48hGe3oikIJezvuFiOZuZd RCpC55F6fYJhHuOZ+QzchsAfSVvxcK6uJzwZAVm4D7AoQkZnFtKYpDEWGVZ5MLDW VjEvA9S0+4zosVFBEQ74bCnfIryZAO2iZ7EEgdlR9QuSm7fO+VJwsWitJyXs7S2P IQzuPmyWjh8z/mgWCmFFcjB2BVRK7Q2mf1Gf4iZ5VmHV0GmyYNb66y1BZqvH7/t1 hiiHDstAtBilw8i+DeWXPReoLRWYrwj5yXNudEynyD1wfWXc8iN23MKtqBQg9XvB 6heboraNMujFGueBDpq7mSOjjt/A9qIwNIN+hz6k9uRXwmiI318WS1i0m/zaqEP6 Aw8KzyZkFHye18TxeqEkhqdmQ0t0YE40tmayr7BLCqr5ufprusulcVaXW7Fep+hZ rnyjI5D0VrsyOUBql7OhEHrsOhV+ybv/yKUOY4BBD6XoVSZN4Jq5UZ85Z7Wuba0E qCaOI8fwphsvnxJT92KCoUYcgl6PDcpP9QfzTqWQ9QX4uBw02SFWdBGREzsyN93r bllK8GBdkzXJoLm7tzK9TCoTdrH9uVQ7mRPvaD1QMLmOngLZ5327sdBTlHFcaEh9 HaG4+RmaCNFaKGP7jq1mHKVPknL0UpioorVqx5ga1+hJb7qSRJh9VXsw6AL5w5CS huh3VeNtqy9ph8xTkfzi =bIsr -----END PGP SIGNATURE----- --BNIEDwiH4xIm1P1gfMCe5UG4Vt8Dluf1t-- From nobody Wed Feb 7 02:29:49 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9536D1271FD for ; Wed, 7 Feb 2018 02:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 1FP0P1x9kiSv for ; Wed, 7 Feb 2018 02:29:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2EB8F1243F3 for ; Wed, 7 Feb 2018 02:29:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejMyx-0006rE-Nm; Wed, 07 Feb 2018 10:29:39 +0000 Date: Wed, 07 Feb 2018 19:29:38 +0900 Message-ID: From: Randy Bush To: Stephen Farrell Cc: "Salz, Rich" , Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:29:48 -0000 > For me, that maybe means CT and the X.509 cert for the domain > is worth a look, so I might actually try a certbot/openssl > CLI hack to see if I can get the contact info into the cert > in a usable manner. contact schmontact. just stash the hash of the signed sec doc. or are you trying to subsume the whole enchilada? > The downside of looking at CT of course is that it's more > likely an attacker could get a new cert from LE for the domain > if they control the web site than it is that the same attacker > could get a new RR published. the point is making them pwn both. but you knew that already. and with the dns as half, the para^Hprudent can bloody well sign their zone. > On the third hand, DNSSEC is still rare while true, there may be a bias toward the kind of folk who would do a sec contact hack. but am not wedded to dns; just the possible semantics thereof. randy From nobody Wed Feb 7 02:59:00 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731A0126C0F for ; Wed, 7 Feb 2018 02:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 xMjQp9IzpZnH for ; Wed, 7 Feb 2018 02:58:57 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0A0124D6C for ; Wed, 7 Feb 2018 02:58:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9A5F6BE5D; Wed, 7 Feb 2018 10:58:54 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98iaF-MTi3O2; Wed, 7 Feb 2018 10:58:54 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51DE4BE47; Wed, 7 Feb 2018 10:58:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518001134; bh=ByBNdcjFxDKb+eN5fYbP72CuU/sJBLKoG6wU/q98EI4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=uzZp2IPhoul+8N0/1SE33o1I4AxrsjZ+gK0G59bdMEBghUrdSVz6iVBMSIXakjsG7 OpvJ9LODeJEERwk0crTt0CkwdCyZ3K/gOAzaQPbE/9Fj/tcjoHYnxXPwdF1KyspViT JXeV/nqbQk7lURJbTsjgRIFn7kdrhu562j2x+v5s= To: Randy Bush Cc: "Salz, Rich" , Security Area Advisory Group References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Wed, 7 Feb 2018 10:58:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LmdDrMWjVl0QDDUkxkO9HHS5eC9VippSr" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:58:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LmdDrMWjVl0QDDUkxkO9HHS5eC9VippSr Content-Type: multipart/mixed; boundary="r8WZ1ZxZbSGOEH8jqWkv2BPvxgx9ZLycm"; protected-headers="v1" From: Stephen Farrell To: Randy Bush Cc: "Salz, Rich" , Security Area Advisory Group Message-ID: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> In-Reply-To: --r8WZ1ZxZbSGOEH8jqWkv2BPvxgx9ZLycm Content-Type: multipart/mixed; boundary="------------F8897BC274CD24D4418A22EF" Content-Language: en-GB This is a multi-part message in MIME format. --------------F8897BC274CD24D4418A22EF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/02/18 10:29, Randy Bush wrote: > contact schmontact. just stash the hash of the signed sec doc. or are= > you trying to subsume the whole enchilada? If the person using the contact information kept history then sure, ct wouldn't add much. OTOH, if ct keeps the history then anyone can go find it, when it's needed/useful. But the ct-angle is just speculation for now, 'till I or someone else goes and tries it out. S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------F8897BC274CD24D4418A22EF Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------F8897BC274CD24D4418A22EF-- --r8WZ1ZxZbSGOEH8jqWkv2BPvxgx9ZLycm-- --LmdDrMWjVl0QDDUkxkO9HHS5eC9VippSr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaetvtAAoJEFqy+vF7FyvqNJIP/3k7Pabc/WL3kT05dPGspE8E piZRve2SvkwFTaIoGh56JgrEiUFIQR61gw+OCGvcCfl34knh09B+cAlanl+xatU7 gq7U4Uaca7+e3llygnj897jcRRhUdJYmjCX1FcU62YvrdZywLlp1WBzuUi2Zhu1x 7v6/ZePpbvHYSWe/C2eTS5WwbVPqpudM4th5V9YQLEM0hJ0fS8mJAOYq1tWJkJ8c RSxiBKSOeZkdzyWvDR+sp0pYAZuAT2/4O1oEabs3QbJN5wB+7jUVHXuzQDGzo37f OWP/G9V3eIAXu1X5Gpevl0UHiwNiSFam5QAMYw2ab0CHOUE3oP7qQt48Y27+P02Z rC+bGruDSBe3UpEHlN1n3/GySKO6R3NdHJpddJjQU/sSI44DU03Zlqz4S4fOM8tG ER95Zth1fu9geKmeiI2+Au1jOo2KcvmpJvyOu6rcfWa24aOR+NZyEXOUhOQYD/4s Pn630r/OFKSa8Y3EAAP5EgCbhHzhZq86StzNBQ2Vc72F6z8zX7ybBz1J9XHvk9W9 J5rtrTlAKbbMqPoIKGpZmuWcsdpMBtIMmcIHaNPTM6hZOdYYncUG0i0PZtBDMxYo 750cVIK1ar7plAQtgKDpckB4GoaG/FXApZwf/YAHfAaRFCft0HU/8JGEy8Y0QUuw hcMWPxuU6/WV3plHmXnA =X2sB -----END PGP SIGNATURE----- --LmdDrMWjVl0QDDUkxkO9HHS5eC9VippSr-- From nobody Wed Feb 7 04:04:34 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC13C129BBF for ; Wed, 7 Feb 2018 04:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 2vWEGwwNrYQp for ; Wed, 7 Feb 2018 04:04:31 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 326DA129516 for ; Wed, 7 Feb 2018 04:04:30 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w17BvEde004826; Wed, 7 Feb 2018 12:04:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=AQEa3TJSJyaSG5pGNGjpJDRohxn3dXG7K7KCzUN/cNs=; b=Gvtf+9KEvuGxDLhC5WG7SNL6Qw52jfH/yhzIlmMioKBTKw8f6sE5rw/NfPOi7ByAf0sj HM+Z9JqogeLQy9Z+RMVfVxAM2Awhe4+09sYLVfP+cSvG9fHk+yZax+HPFTrGoUuB91Bx CZvtgULBYHG8cz5oXvVIho0U8VFsN5YAbKD+pDngivV76KbsJLjPbfTSWo3SUnOSvpIH 7clhkjn5UNh1NTs/TYL3kxypOa5A8PEWS/EnmX2qjPOXCo96aFWGCe7HpFWmKaeRcSn6 NCTusqeNBi15bV3//YDz8WNQtq02RSnFqsW4tuEsmuGPt/CGG5lH5YTtoErK5lFrpHK6 vA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2fw5kxc5hq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 12:04:28 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w17C2ADc004559; Wed, 7 Feb 2018 07:04:27 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fw9a12gqw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 07:04:27 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 7 Feb 2018 07:04:25 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 7 Feb 2018 07:04:25 -0500 From: "Salz, Rich" To: Yakov Shafranovich , Randy Bush CC: Security Area Advisory Group Thread-Topic: [saag] New Version Notification for draft-foudil-securitytxt-02.txt Thread-Index: AQHTno0YQ/zmuRL1906ONjdVNg9FvKOXyTAAgAB3KgCAACAzgIAAHNcAgAAGgYCAAANGAIAAAe+AgAADsoCAAA/CgIAAkcGA Date: Wed, 7 Feb 2018 12:04:25 +0000 Message-ID: <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.92] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=697 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070152 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=649 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070151 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:04:32 -0000 4p6iIEFuZCBteSBvdGhlciBxdWVzdGlvbiBpcyByZWdhcmRpbmcgdGhlIGhhc2ggaXRzZWxmLCBp cyB0aGVyZSBhbiBlYXN5DQogICAgd2F5IHRvIHNwZWNpZnkgdGhlIGhhc2ggZnVuY3Rpb24gbmFt ZSBiZWNhdXNlIFNIQS0yNTYgd2lsbCBiZQ0KICAgIGRlcHJlY2F0ZWQgc29tZWRheS4gSSBjb3Vs ZG4ndCBmaW5kIGEgc3RhbmRhcmQgd2F5IHRvIHNwZWNpZnkgYW4NCiAgICBhbGdvcml0aG0gYW5k IGEgaGFzaCwgdGhlIGNsb3Nlc3QgdGhpbmcgaXMgTkksIHdoaWNoIHNlZW1zIGNsdW5reToNCiAg ICAibmk6Ly8vc2hhLTI1NjtVeWFRVi1FdjRyZExvSHlKSldDaTExT0hmcll2OUUxYUdRQWxNTzJY Xy1RIg0KICAgIA0KVGhlIHMvbWltZSBzaWduYXR1cmUgZm9ybWF0cyBpbmNsdWRlIHRoZSBhbGdv cml0aG1zLCBpdOKAmXMganVzdCBub3QgaW4gcmVhZGFibGUgdGV4dC4gIFdlIGFsc28gaGF2ZSBw Z3AgZm9ybWF0Lg0KDQpUcnlpbmcgdG8gc3RhcnQgYW5vdGhlciBvbmUsIG9yIGdldCBpbnZvbHZl ZCBpbiB0aGF0IGZvcm1hdCB3YXIsIHdpbGwgaHVydCB0aGUgY2F1c2UuDQoNCg== From nobody Wed Feb 7 04:17:48 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A792D129C6B for ; Wed, 7 Feb 2018 04:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 gtYBju2COc0w for ; Wed, 7 Feb 2018 04:17:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2C597124205 for ; Wed, 7 Feb 2018 04:17:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejOfT-00027A-UI; Wed, 07 Feb 2018 12:17:40 +0000 Date: Wed, 07 Feb 2018 21:17:38 +0900 Message-ID: From: Randy Bush To: "Salz, Rich" Cc: Yakov Shafranovich , Security Area Advisory Group In-Reply-To: <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:17:45 -0000 > =E2=9E=A2 And my other question is regarding the hash itself, is there an= easy > way to specify the hash function name because SHA-256 will be > deprecated someday. I couldn't find a standard way to specify an > algorithm and a hash, the closest thing is NI, which seems clunky: > "ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q" > =20 > The s/mime signature formats include the algorithms, it=E2=80=99s just no= t in > readable text. We also have pgp format. >=20 > Trying to start another one, or get involved in that format war, will > hurt the cause. it is not like we need pfs here. and sha256 is likely to last a month or two randy From nobody Wed Feb 7 04:31:48 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB6C12DA25 for ; Wed, 7 Feb 2018 04:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 bjdsVdzN1vYa for ; Wed, 7 Feb 2018 04:31:45 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 638E412AF77 for ; Wed, 7 Feb 2018 04:31:45 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id 24so523576oij.3 for ; Wed, 07 Feb 2018 04:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T7ep8F21rbxFvKAlc1xenrIGf/PKeX9VpeNojnNvSjE=; b=uIR+W0mNh01Eq16d53IuwtRPM8bXDyZH8ztsNy/MdiicqwDlNxv0WcvqLfZqhQA/x/ jX7SDfRyFxoDoXDRo552Zwr2/pzETUaVMivDaMJCGDtlY3gEjOlOd6qQBC/9c6uHOvnj aliJtMjycoslko3vt/NwP6+ylFBYtDCFDm/yRRZRGGrwU9dSUweWB6KgW+64lTIURJ/0 FJKc6KfxvBsCZ1q51ADxsVm8UenkhzrVD8057pw+bdsSP1Lof/uNrPIS3Yk8sahiLDYh K5KE0mpLP/ye8F7MA3++f9pfC9e3X+XyBKlcLFRA+/PmfJSXRVlUGfVxY9Ub5v24KEjZ lEsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T7ep8F21rbxFvKAlc1xenrIGf/PKeX9VpeNojnNvSjE=; b=tf9XTgldjJjvva53VG6k68J1MumUwfO2fh9aeYcMnl8xwCx8t9SxYuHrYUTHHnRvTk OfmB2J/UnqvRoIQdtqiQtjGreQM4ql0ji5mWF5EjPGVZ2J4X/Mn4w/GI76yEYtRpVlRr L6Vwv/OdX2GXg/SMCT/MxArFMPg4x9nljVm0eQPH1MCypiQYsM4x2MmrpVNZSnrHMYao kf9vw3B2STEjdYUHvKCiGhoNVbJ6tJfqZsKWOYnNKSC+ia6ar1YDNQqeX4wFxGazcEX4 +BlC3kAm6oWnmhvCRp3WM3HVGGOicm/x0O5NiBI2baxRSLpCF0EQJb8J7Ro15Q6eZkyW upqw== X-Gm-Message-State: APf1xPCiMx2AY5VwWx2itsQ66KrP5nNoDI6MTQSwr6vW70mkZ772j3yL 6f5Be+FdXrZTZ4lQI/io+UEZ5eB/lMVrz1Ns0wvlOIES7dc= X-Google-Smtp-Source: AH8x226r6FjxAV4KzOWIkcleSH6MkjDLKLrOkReivLsd9EVTije9bNrM6BjJ6wD5RfMjkeevaOA/7f+Bb+VQ5zllNVg= X-Received: by 10.202.216.69 with SMTP id p66mr4043669oig.100.1518006704637; Wed, 07 Feb 2018 04:31:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 04:31:04 -0800 (PST) In-Reply-To: <47e4b4ef-1042-a702-ca01-fee7fab5a867@ripe.net> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <47e4b4ef-1042-a702-ca01-fee7fab5a867@ripe.net> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 07:31:04 -0500 Message-ID: To: Robert Kisteleki Cc: saag Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] (was: Fwd: New Version Notification for draft-foudil-securitytxt-02.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:31:47 -0000 Hi Robert, Multiple people expressed that concern and in the upcoming -03 version this has been changed to a regular URI with "mailto" and "tel" in it: https://github.com/securitytxt/security-txt/issues/62 https://github.com/securitytxt/security-txt/blob/master/draft-foudil-securitytxt.txt#L218 There is also a related issue currently open about a user asking whether JSON can be supported as an alternative format: https://github.com/securitytxt/security-txt/issues/12 Thank you On Wed, Feb 7, 2018 at 4:04 AM, Robert Kisteleki wrote: > > Hi, > > The document states (in 1.1 Motivation) that the goal is to make the > document machine-parsable. However, when describing the format for > Contact: lines in 2.3, it allows using email addresses to be included > "without a prefix for ease of use and readability" (it's a SHOULD, not a > MUST). > > Ease of use and [human] readability is not real concern is the intention > is to be read by machines. On the other hand, the above flexibility will > lead to the need to use regular expressions (or such) to find and parse > the actual email address if one wants to implement automatic > notifications to such addresses. So I feel that this flexibility is > actually a drawback -- I believe the draft should mandate "proper" syntax. > > As an alternative, one could split the contact lines into contact-web, > contact-phone, contact-email, contact-postal, ... IRR style entries instead. > > Regards, > Robert From nobody Wed Feb 7 04:36:27 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AB1124205 for ; Wed, 7 Feb 2018 04:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 DwJgWPJNgd_h for ; Wed, 7 Feb 2018 04:36:24 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 374441241FC for ; Wed, 7 Feb 2018 04:36:24 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id a2so646722otf.2 for ; Wed, 07 Feb 2018 04:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D2y7ssViDPzNI3TaTIGGe9tqjDzYeDDmBSrK9PRrv6A=; b=cLeYliQOuY9lfqpMqHjVv9+ZAj7vSGPV9RrGYspyvGbP6jtKRRWnp6mhMY2LuJvpll Of62ycETZXNJAQG00eH6Uyw2S8F7VsOJViunjWNkTa8P3DZf/OaoO4nyOlaXRpYFKvVY NimK4em0eVfh0FO9B4GhmmsrtsK8fMix+gCJ7iPfRmBULd2x4tSLSsMMLqGn3FsSXnca OwJxMIhvc7tNXdHzPWEe/VDKgNiMHRtBqrE7t8KsjLV6XmEknWsBqaHVJ/V5QaPLNZDi P7okSFl8Km/kzuefznc9ibTdohdkNKzDLceiTMnF4AMR2GGoa9gKX/80rGgS8Mc7DLmW 110Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D2y7ssViDPzNI3TaTIGGe9tqjDzYeDDmBSrK9PRrv6A=; b=pIZmhrTvXibDkysqdRHH6zkD3qZyr1aGMvUR/IDYgXRTQ3WfsXKfewHCRerASoJQLE 8mkaMj8VLjShfYsm+hAyufbqfoP5SzMAXC+hyXZF9pv1nKReccjjT9q1bUiyAvN7MXV+ zaggvKZ7bZENS5OKsNexLXnsW8TLymTSRYOsMNBlNZ+F4VE6VCKtWO2yM2kmzPRG34Vn lQA2itVV8CezQPDOpcSL6i7T0PdWwWd6HCuAbenHx6FDEqt5Mf6hmjpRAph1O5zI+74z giI+ukPNx8WBvbwjRSh2CChwtfYzOj1jenXBFwQZrn3SaO1jauzKdUdhkI+SOcrx/Voq c9nw== X-Gm-Message-State: APf1xPCoRMuGK/h+mYYzluKo98ZK5GcVK9iaDMm49Xe+ltw5GaXZ1kIL npjnSQs1JLd8myrYKkiDAhw41txwtS2i48KYw6C4s5fM X-Google-Smtp-Source: AH8x226xhsddB4Kw/rCsr8BKXSRWN6FOR/BRX2cuv2HaDrC9/aciBj+Whod6hoHIN/SnXmNWpeH+P4pn/Iuh6vm27WY= X-Received: by 10.157.2.167 with SMTP id 36mr4032843otl.23.1518006983525; Wed, 07 Feb 2018 04:36:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 04:35:43 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 07:35:43 -0500 Message-ID: To: Stephen Farrell Cc: Randy Bush , "Salz, Rich" , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:36:26 -0000 On Wed, Feb 7, 2018 at 4:36 AM, Stephen Farrell wrote: > > The downside of looking at CT of course is that it's more > likely an attacker could get a new cert from LE for the domain > if they control the web site than it is that the same attacker > could get a new RR published. So a certbot/openssl approach > probably makes the current value less trustworthy than a DNS > based approach. The historical values are still good though > and the change could in itself be a useful signal. > This is especially true since the same ".well-known" directory is used by LetsEncrypt for domain verification via ACME before issuing an SSL certificate, so an attacker that can modify a "security.txt" file in that directory can probably pass the ACME check as well. > > Lastly, as another off-the-wall idea, archive.org could be a > third party for this if the URL ends up is crawlable. That's > probably not really dependable enough though. > A member of our project has also put up a prototype crawler that does something along these lines here: https://registry.securitytext.org/ Thanks From nobody Wed Feb 7 04:44:47 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6CF126C22 for ; Wed, 7 Feb 2018 04:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 dF-gZVvFZKOi for ; Wed, 7 Feb 2018 04:44:44 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 666F11241FC for ; Wed, 7 Feb 2018 04:44:44 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id m83so543523oik.8 for ; Wed, 07 Feb 2018 04:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7PU/OkjRiP49WA3Lz/d3a8O46IHCIvf+wqp/MskyYnI=; b=MUl9OQcKP7ppdL3nr1zGfzkP4f/Ad6iCmNGjW1IzTtM4Wm0wNy6Ljefj/BnJJt/HLG uvFWcX+pawOP3ZQZcxwtC/4ismF87sEB/rTHjO3Whe8CO2cLHpyPXHvMwqsjw1vBGBXA nM+WHq6FWVZN7k0Sh4vkBxhtUG1hnzfSxm7Mxa7V0YMA3Izo0Y8g8rEYMKXthXT9fEyA u8yDSsqlC7BaV1GDAK5dbR2YGM08pnJeW4DIrRLLIG9twjSYF+P23gM3I0ppBjQpXoeS 8ZR045e8XHSnUIVXE4j5+rcL+s6PPHPw5RUzVAqVUogZPxXEXhFZgw40kbyFMghA4tcR In2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7PU/OkjRiP49WA3Lz/d3a8O46IHCIvf+wqp/MskyYnI=; b=VFWfq5F40t2qZPhyKIhU2pnnDI3IlNlykkgpvQr2+lEGu787QLQumEYFXOrLHMOf1R jMAMDahUaO+K+GlhycnAc9spW2za3bh5xfKay8jgBmWhc1+GjsQAUWa+WmnpFBmTKlSF LaPRugxLr6iQrY4qDY8EYMuIcFiZOPhCBL1Ak9KlMTKRHKGuncz/DwbNMqwfOOhniu0/ qm2RYK5ridtm9/+8idIswCr2p9Jt72CoVc5td9RRTWkPH91tU3n8qTiwWUdHZDRd5ElD V8MbReVfrpyw1fkE+JPkGWIFUk6ctGksiHuHBaybgHPdkZ+dkLV+ss0OtJQWxaMa9OPa KbJA== X-Gm-Message-State: APf1xPAdaYsDVrZxNNmSZnMP2CHyzdNaeJEKjKFi3G0Zm0NsEL+6Q+LJ zDI2UhXQlbD/ZRuSQYbW+diVLz2aM4x2gmZAT6d1ew== X-Google-Smtp-Source: AH8x2251PaLBJMwsm2zixf057qVo1h9PY7L7myYzK+JbC22UO66NIwV+sxIpOz1b4Ia/erRaYFhgZNQ40IARZOMeAws= X-Received: by 10.202.46.83 with SMTP id u80mr3440953oiu.143.1518007483485; Wed, 07 Feb 2018 04:44:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 04:44:03 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 07:44:03 -0500 Message-ID: To: Randy Bush Cc: "Salz, Rich" , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:44:46 -0000 On Wed, Feb 7, 2018 at 7:17 AM, Randy Bush wrote: >> =E2=9E=A2 And my other question is regarding the hash itself, is there a= n easy >> way to specify the hash function name because SHA-256 will be >> deprecated someday. I couldn't find a standard way to specify an >> algorithm and a hash, the closest thing is NI, which seems clunky: >> "ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q" >> >> The s/mime signature formats include the algorithms, it=E2=80=99s just n= ot in >> readable text. We also have pgp format. >> >> Trying to start another one, or get involved in that format war, will >> hurt the cause. > > it is not like we need pfs here. and sha256 is likely to last a month > or two > As stated in the other thread, it seems that webspace gets compromised more often than DNS, although for the various blockchain / ICO projects, DNS has been attacked more often. Even without DNSSEC the DNS solution maybe "good enough". I like Randy's approach for simplicity and I think it may be "good enough" for this use case. The one thing I would suggest is perhaps placing the SHA-256 hash under a standard name for the domain or subdomain where the security.txt file lives as follows: "hash._securitytxt.example.com" or even just "_securitytxt.example.com", and the hash would be in a TXT record. As far as monitoring is concerned, we do currently have language in the upcoming -03 version asking organizations to monitor their own files. Perhaps this can be expanded to encourage wider monitoring of these files by third parties as well. Thanks From nobody Wed Feb 7 07:34:06 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921FA12D77E for ; Wed, 7 Feb 2018 07:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 tgnO0yATHJtF for ; Wed, 7 Feb 2018 07:34:02 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 BFC13120454 for ; Wed, 7 Feb 2018 07:34:02 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5D0F12823AA; Wed, 7 Feb 2018 16:34:01 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 56CD0282407; Wed, 7 Feb 2018 16:34:01 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 501002823AA; Wed, 7 Feb 2018 16:34:01 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 4D92A61083FE; Wed, 7 Feb 2018 16:34:01 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 474C1401C7; Wed, 7 Feb 2018 16:34:01 +0100 (CET) Date: Wed, 7 Feb 2018 16:34:01 +0100 From: Stephane Bortzmeyer To: "Salz, Rich" Cc: Yakov Shafranovich , "saag@ietf.org" Message-ID: <20180207153401.lxcdrmtnbp6wjqrn@nic.fr> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <98C9A08F-8A1A-4D67-A1FE-6787EF1730DC@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98C9A08F-8A1A-4D67-A1FE-6787EF1730DC@akamai.com> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000112, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.7.152415 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:34:04 -0000 On Mon, Feb 05, 2018 at 09:12:25PM +0000, Salz, Rich wrote a message of 6 lines which said: > OpenSSL is also doing it, as an experiment. https://www.openssl.org/.well_known/security.txt 404 It seems they removed it. From nobody Wed Feb 7 07:36:36 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3BE12D7EB for ; Wed, 7 Feb 2018 07:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 mHMqFM-WbJjD for ; Wed, 7 Feb 2018 07:36:29 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 F3E5312D77E for ; Wed, 7 Feb 2018 07:36:28 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 90AD728070D; Wed, 7 Feb 2018 16:36:27 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 8A8F02808F6; Wed, 7 Feb 2018 16:36:27 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 8390428070D; Wed, 7 Feb 2018 16:36:27 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 8037361083FE; Wed, 7 Feb 2018 16:36:27 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 76D70401C7; Wed, 7 Feb 2018 16:36:27 +0100 (CET) Date: Wed, 7 Feb 2018 16:36:27 +0100 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: Randy Bush , Security Area Advisory Group Message-ID: <20180207153627.6gaxazse2gv3vr5c@nic.fr> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.7.152716 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:36:30 -0000 On Tue, Feb 06, 2018 at 04:52:44PM -0500, Yakov Shafranovich wrote a message of 74 lines which said: > rely on the fact that it is harder to compromise DNS vs. the > web. Empirical evidence suggests that may be true but I am not > entirely sure. I suggest we do not try to find out whether DNS is secure than the Web or the opposite. Instead, we could rely on the fact that it is at least harder to compromise both DNS and the Web than the DNS alone or the Web alone. So, putting info in the Web and a way to check it elsewhere (in the DNS) seems reasonable. We don't want a military-grade solution, just something that it is not obvious for an attacker to compromise. From nobody Wed Feb 7 07:40:51 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F4512DA48 for ; Wed, 7 Feb 2018 07:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 iL9-u7Kp7-ij for ; Wed, 7 Feb 2018 07:40:47 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 7B85212D87E for ; Wed, 7 Feb 2018 07:40:47 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 0CEF9282432; Wed, 7 Feb 2018 16:40:46 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 0636E28260A; Wed, 7 Feb 2018 16:40:46 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id F376B282432; Wed, 7 Feb 2018 16:40:45 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id F03536423521; Wed, 7 Feb 2018 16:40:45 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id E6642401C7; Wed, 7 Feb 2018 16:40:45 +0100 (CET) Date: Wed, 7 Feb 2018 16:40:45 +0100 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: Randy Bush , Rich Salz , Security Area Advisory Group Message-ID: <20180207154045.dm2yvecrv4qz3keg@nic.fr> References: <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.7.153317 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:40:49 -0000 On Tue, Feb 06, 2018 at 09:26:21PM -0500, Yakov Shafranovich wrote a message of 21 lines which said: > My question is really around whether there specific guidance for > subdomains like these in DNS? Yes, RFC 5507 and 6950. They are long documents, so here is a one-line summary: If you use TXT records, don't put them in the apex of the domain but underneath. So, _securitytxt.example.com but not example.com. > SPF (RFC 7208, section 3) on the other hand puts stuff in a TXT > record for the apex domain, and doesn't use subdomains. Yes, but it was done a long time ago without thinking, and it is hard to change it afterwards. > I also remember back when I was involved with SPF et al, the use of > TXT records was frowned upon, although that seems to have changed. Indeed, the conclusion was that, although SPF was cleaner, TXT won: RFC 6686. From nobody Wed Feb 7 07:43:49 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3230212DA6E for ; Wed, 7 Feb 2018 07:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 L45hkib0R1k4 for ; Wed, 7 Feb 2018 07:43:41 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 1100912D7F2 for ; Wed, 7 Feb 2018 07:43:39 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 9FE78282432; Wed, 7 Feb 2018 16:43:37 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 98FB528260A; Wed, 7 Feb 2018 16:43:37 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 924C2282432; Wed, 7 Feb 2018 16:43:37 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 8F0F061083FE; Wed, 7 Feb 2018 16:43:37 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 7CCEE401C7; Wed, 7 Feb 2018 16:43:37 +0100 (CET) Date: Wed, 7 Feb 2018 16:43:37 +0100 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: Randy Bush , Rich Salz , Security Area Advisory Group Message-ID: <20180207154337.qidhussey6u2jwxy@nic.fr> References: <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.7.153317 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:43:43 -0000 On Tue, Feb 06, 2018 at 10:22:45PM -0500, Yakov Shafranovich wrote a message of 29 lines which said: > And my other question is regarding the hash itself, is there an easy > way to specify the hash function name because SHA-256 will be > deprecated someday. I couldn't find a standard way to specify an > algorithm and a hash, the closest thing is NI, which seems clunky: > "ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q" I have no problem with RFC 6920 (NI). The future RFC 8315 (which is in AUTH48-DONE) uses sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= From nobody Wed Feb 7 07:46:10 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3871126E3A for ; Wed, 7 Feb 2018 07:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 p37-2iWarAjp for ; Wed, 7 Feb 2018 07:45:42 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 A015A12DA6D for ; Wed, 7 Feb 2018 07:45:42 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 338A5282432; Wed, 7 Feb 2018 16:45:41 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 2CD1128260A; Wed, 7 Feb 2018 16:45:41 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 263D2282432; Wed, 7 Feb 2018 16:45:41 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 22D1261083FE; Wed, 7 Feb 2018 16:45:41 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 190F8401C7; Wed, 7 Feb 2018 16:45:41 +0100 (CET) Date: Wed, 7 Feb 2018 16:45:41 +0100 From: Stephane Bortzmeyer To: Martin Thomson Cc: Yakov Shafranovich , saag , Ed Overflow Message-ID: <20180207154541.wgr7mtmwx2yymnd4@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.002450, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.7.153616 Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:45:53 -0000 On Tue, Feb 06, 2018 at 11:59:49AM +1100, Martin Thomson wrote a message of 44 lines which said: > Have you considered formatting the signature as a certificate and > submitting it to a CT log? That gives you an audit capability. I wasn't present at the beginning, but it seems to me that the entire point of security.txt was to have something light-weight? If we need to set up CT logs or blockchains for it, doesn't it defeat the point? From nobody Wed Feb 7 08:01:26 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658E512DA73 for ; Wed, 7 Feb 2018 08:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 3EiBqjF1p5G8 for ; Wed, 7 Feb 2018 08:01:22 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F23126D05 for ; Wed, 7 Feb 2018 08:01:21 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D82AF7D679; Wed, 7 Feb 2018 16:01:20 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-51.brq.redhat.com [10.40.204.51]) by smtp.corp.redhat.com (Postfix) with ESMTP id 914BA2024CA5; Wed, 7 Feb 2018 16:01:16 +0000 (UTC) To: Yakov Shafranovich , Martin Thomson Cc: Ed Overflow , saag References: From: Paul Wouters Message-ID: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> Date: Wed, 7 Feb 2018 11:01:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 07 Feb 2018 16:01:20 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 07 Feb 2018 16:01:20 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pwouters@redhat.com' RCPT:'' Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:01:25 -0000 On 02/06/2018 05:38 PM, Yakov Shafranovich wrote: > Hi Martin, > > Thank you for the suggestion. Is there anyone today using the CT logs > system for tracking things other than certificate issuance? I'm working on DNSSEC transparency, hope to have something for IETF 101 that resolves questions raised before on this topic. >>> What I am wondering if there are any currently best accepted practices >>> to accomplish these goals in DNS with minimum disruption to the >>> Internet architecture as whole. Possibilities I was thinking of is >>> using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT >>> records like DKIM and SPF. How many times can the WEB depend on DNS(SEC) without claiming it is not depending on it? If DNS is more trustworthy then content served by a webserver, then why not store the security contact information only in DNS? Like SMIMEA or OPENPGP records for security@domain. The new draft that adds an optional signature file is just not good enough. It still allows for administrators to publish security information that is completely untrusted and spoofable. In 2018 we should not do security protocol work that depends or allows unauthenticated data from any source. The draft could fix this by making the signature mandatory as part of the .txt file. But still, even when signed, a compromised server can use a false key that appears real, has been uploaded to known pgp keyservers, etc. So it still needs to be anchored in some trustworthy external party. We already see people using this file as an embedded LinkedIn advertisements. It will be just as horrible as WHOIS free flow formats. So, if we really want a standardized way to provide this information, go do this in RDAP. It does not depend on the zone's DNS, does not depend on a compromised web server, and its format is meant to be very computer consumable. If that is "too difficult" for admins to do, then maybe security isn't their thing to begin with. Paul From nobody Wed Feb 7 08:07:59 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95261201F8 for ; Wed, 7 Feb 2018 08:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 qpTqoR249ZDx for ; Wed, 7 Feb 2018 08:07:56 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C7512E034 for ; Wed, 7 Feb 2018 08:07:51 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EF6444075171; Wed, 7 Feb 2018 16:07:50 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-51.brq.redhat.com [10.40.204.51]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3814E2166BAE; Wed, 7 Feb 2018 16:07:49 +0000 (UTC) To: Yakov Shafranovich Cc: Security Area Advisory Group References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> From: Paul Wouters Message-ID: <1b966f93-0a6a-1067-b6db-479f2f03cec8@redhat.com> Date: Wed, 7 Feb 2018 11:07:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 07 Feb 2018 16:07:51 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 07 Feb 2018 16:07:51 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pwouters@redhat.com' RCPT:'' Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:07:58 -0000 On 02/07/2018 07:44 AM, Yakov Shafranovich wrote: > As stated in the other thread, it seems that webspace gets compromised > more often than DNS, although for the various blockchain / ICO > projects, DNS has been attacked more often. Even without DNSSEC the > DNS solution maybe "good enough". That's a low bar. In practice, it seems people have a pretty good success rate just finding the company's twitter account and letting them know via social media. And that seems vastly more secure then an untrusted security.txt file backed by untrusted DNS. Paul From nobody Wed Feb 7 08:09:25 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A24712704A for ; Wed, 7 Feb 2018 08:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 XaesVtGUFsxn for ; Wed, 7 Feb 2018 08:09:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7321201F8 for ; Wed, 7 Feb 2018 08:09:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AE094200A3; Wed, 7 Feb 2018 11:15:54 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F192580F9C; Wed, 7 Feb 2018 11:09:20 -0500 (EST) From: Michael Richardson To: Yakov Shafranovich cc: Randy Bush , Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:09:24 -0000 --=-=-= Content-Type: text/plain Yakov Shafranovich wrote: > As stated in the other thread, it seems that webspace gets compromised > more often than DNS, although for the various blockchain / ICO > projects, DNS has been attacked more often. Even without DNSSEC the > DNS solution maybe "good enough". DNS is good enough. Those that want better can and should deploy DNSSEC. We don't need to boil the ocean here. While I like having a PGP signed object there (and I think we should accomodate it), I doubt it will have any significant web of trust. Or to put it differently: anyone with a PGP web of trust on their signature probably will never need to be contacted :-) > I like Randy's approach for simplicity and I think it may be "good > enough" for this use case. The one thing I would suggest is perhaps > placing the SHA-256 hash under a standard name for the domain or > subdomain where the security.txt file lives as follows: > "hash._securitytxt.example.com" or even just > "_securitytxt.example.com", and the hash would be in a TXT record. +1. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp7JLAACgkQgItw+93Q 3WU1lwgApha9t5U7vFmVH46Ig8AUcbcstcuRPPxuFuY34WABgS6p96cbUtw1dNNn B55e/O0dObGvArsmGRrhOr7lIYIFQ9NC38sYdiWXnn7Ebj/+e45ZE8StHNc+Pkqq 9tjCH4vOYt3bdE+ELdfkYm6K5vikXc3K54NgwYFXdPP33gN6ez6hzjBAKZ+3Kv0b ak+xLy6uRWA7dl6ETyB//fN7T9QxQz2Se51hzFu76TPSpAVnSJCKSqoLIRrTY0vW M0OxeDhphBcphBANLAtOsG170D1ZR3VnEeg0kp1KpBfqgmd32RmA0dYMFefaysqr NJgGiPv1M47hf/Ej5TMHBl0B3dnEdA== =MBbO -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 7 08:10:20 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D412F12DB70 for ; Wed, 7 Feb 2018 08:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 OHaN9ADuRohb for ; Wed, 7 Feb 2018 08:10:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1995712DDD0 for ; Wed, 7 Feb 2018 08:10:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 973E9200A3; Wed, 7 Feb 2018 11:16:49 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D701B80F9C; Wed, 7 Feb 2018 11:10:15 -0500 (EST) From: Michael Richardson To: Robert Kisteleki cc: Yakov Shafranovich , saag In-Reply-To: <47e4b4ef-1042-a702-ca01-fee7fab5a867@ripe.net> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <47e4b4ef-1042-a702-ca01-fee7fab5a867@ripe.net> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] (was: Fwd: New Version Notification for draft-foudil-securitytxt-02.txt) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:10:20 -0000 --=-=-= Content-Type: text/plain Robert Kisteleki wrote: > The document states (in 1.1 Motivation) that the goal is to make the > document machine-parsable. However, when describing the format for > Contact: lines in 2.3, it allows using email addresses to be included > "without a prefix for ease of use and readability" (it's a SHOULD, not a > MUST). If that's a goal, then please make it JSON. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp7JOcACgkQgItw+93Q 3WVVVwgAok3HH0FbEbQI8nWHSNWvFXazDGa6mqjUIbb8hWiui3+3KFuxVnYbJGpL SdGOYWKW/F88TGpSaMz+tIlOfYSl3GDQAiDJVA1ZemA49HugnGb6mZ9jni8rcz74 lyPeiNBR/tg9jWLlakDI65RVAxalK53lyDoo0ibuC1Qr3y/Qq9iD3lsqIiGpW4sN E/e78QbbNLXjaN1R9xN0E4KFZrEGXoLHZTHEKhvvHUAZQr3uBFAhMILLNCGBdO/p Hs9paJTe7JtA1zH4XqQ6bi6DuxmBVFcWHtfqeE6bL61mVhHom4MBTw7BBNd/fFhN XY+8rREZy5OA6C9S8xu5brG+aprUPg== =3KhN -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 7 09:17:42 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFD91270AC for ; Wed, 7 Feb 2018 09:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 r_-lcrWGJAUe for ; Wed, 7 Feb 2018 09:17:37 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 C6F2B1242F7 for ; Wed, 7 Feb 2018 09:17:37 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w17HHYHt006612; Wed, 7 Feb 2018 17:17:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=UwIfXLYgvvYhCzM8Zl2CKNiG9+xC8ehfkFPQkhBbRkg=; b=ZVZDXCokbI7GtOe6bnU4YrOZONCz1TEd34c2QBk2qPnjFUqOYr3hyD5/1/2WAnXiJblJ fiLn3WYhronX0HvbjsE/brYHR7+DeTPinVoLzNdm7j5rMnj1InysJR+v1tMYxXWYCgM6 fdic6gZjLjRyOmh6VocWJdKVBm/IaPDyU+15EfwATdwUlPzrNXSR4HoRYgnXIF9Klal9 fTUSgPsU5sfZm38ie+0iYCILUNECOhV9FvA3KnVPc9e3j+Se4DlSa3m6xaNkhE2DLn07 zzxIOncZ1wrl1C5mud3S2uawYJOLKnsNzQhZmSWWBnm+eVplifgxY/g1VrseNGOl6Tkc 8Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2g03mc8bn7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 17:17:34 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w17HGbcU009686; Wed, 7 Feb 2018 12:17:27 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fw9a139nm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 12:17:27 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 7 Feb 2018 12:17:25 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 7 Feb 2018 12:17:25 -0500 From: "Salz, Rich" To: Stephane Bortzmeyer CC: Yakov Shafranovich , "saag@ietf.org" Thread-Topic: [saag] New Version Notification for draft-foudil-securitytxt-02.txt Thread-Index: AQHTno0YQ/zmuRL1906ONjdVNg9FvKOWosGAgALGHoCAABzagA== Date: Wed, 7 Feb 2018 17:17:25 +0000 Message-ID: <5C21D498-FC95-4F44-A6C3-5938F9730726@akamai.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <98C9A08F-8A1A-4D67-A1FE-6787EF1730DC@akamai.com> <20180207153401.lxcdrmtnbp6wjqrn@nic.fr> In-Reply-To: <20180207153401.lxcdrmtnbp6wjqrn@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.19] Content-Type: text/plain; charset="utf-8" Content-ID: <72B553EF2DF7F84BAFED566D33AFE068@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=761 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070218 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=711 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070218 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 17:17:40 -0000 VHlwbywgc29ycnkuDQoJaHR0cHM6Ly93d3cub3BlbnNzbC5vcmcvLndlbGwta25vd24vc2VjdXJp dHkudHh0DQoNCmRhc2ggbm90IHVuZGVyc2NvcmUuICBPb3BzLg0KDQoNCg0K From nobody Wed Feb 7 10:10:38 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFDC124F57 for ; Wed, 7 Feb 2018 10:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 OODG5q7-bRTT for ; Wed, 7 Feb 2018 10:10:31 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 14B8012D865 for ; Wed, 7 Feb 2018 10:10:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejUAp-0000D8-1l; Wed, 07 Feb 2018 18:10:23 +0000 Date: Thu, 08 Feb 2018 03:10:21 +0900 Message-ID: From: Randy Bush To: Yakov Shafranovich Cc: "Salz, Rich" , Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:10:36 -0000 > The one thing I would suggest is perhaps placing the SHA-256 hash > under a standard name for the domain or subdomain where the > security.txt file lives as follows: "hash._securitytxt.example.com" or > even just "_securitytxt.example.com", and the hash would be in a TXT > record. you seem not to have read my mesage % dig +short security.txt.sig.rg.net. txt "fa1dce4207c0087d19d949bb600613fff2bcd2933e76749afedcb8e5500e70a9" From nobody Wed Feb 7 11:03:15 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9903C127444 for ; Wed, 7 Feb 2018 11:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 0EHEzpp5diOW for ; Wed, 7 Feb 2018 11:03:12 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.207]) (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 20F7C1270B4 for ; Wed, 7 Feb 2018 11:03:12 -0800 (PST) Received: from [216.82.242.36] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-15.bemta-8.messagelabs.com id 55/2F-03101-F6D4B7A5; Wed, 07 Feb 2018 19:03:11 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURiFe6fTdkBqhhbkl0CU6oMhaVMianG LDxqIiFHURIhRBhnaxraQTlGWGJGICYJsVoWC4IJLABM3FIkoElFAqpEoNqjBhl2siBoXXGc6 BfXtu/ec+58zN3cIoWxEHEjQ6RbabKIMCrE37ph7Ta00xWTFq99/DtFc/9mCND1dv5DGWpSHa ZqedYpX4VFV319iUTdtryRRNTXfsKjBsXv4BjxepDclpqQniHTtQ4N46kB0emGXS5SNLkYeQt 4ETo5j8Pa7U8QtZOQRDLodpRJ+0YbgxdATVvEixKQaepofYBz7kclw0nYOcSwkV8Lxc3Vuj5z cDD1tvTjv2QLOhjIxz0uhveKU+yxOzofLtmI3S8ltkHPmmif5GIJaV4l7kBe5EeylDW4TImfB l856jA8LgN6BajcD6QfOJw/FPPvDaP8vEe/fBic+tnr2FfDi4lfEczB0V+cjLgzIHgmcrWwQ8 YIKGkpcHlMM2F85cd6Uh0GO7bOEF0Kh7MNrVpCwvAsuGPndaBh6dNUzcxhjSxzwlAuCifwyj1 Aghvq6ZneAjEwCa+1Uuyw4PfkBL0ahtn8+zsaeEZLV7NWXW0U29zX5Qkf5AM6blNB0u0XI8xy 44ar08DIom7wr5jkErPlOCc+LYKxtAp1ERC1awNDm3bRZGbZElWjWa3UWI6U3KMPUGpWRZhhK SxuoREa1M8V4BbHvbZ9AgBrRpYm4VjSbwBT+0v5TmfGymYkpSRk6itHtMKcZaKYVBRGEAqS96 7LiZb5mWkunJ+sN7KOdkoHwUfhJczlZyqRSRkav5aVOtJB4enz4oJBwjIwdFMpwU4qJDgyQXu CsJGfVpZmmB039AN0oOFAuRQKBQOaTSpuNesv/+hsUQCCFXLqdm+KjN1mm896wVTC2iiM2g6t iof5KgdloNGa1ZsSrylUTMSNiPKhP/hQzjvZj80rlm9erZy/tK8zymavKuPU8R1syeZ/xt9uf VX2xzqocpAoNX8M7IeZTIdMbWR++6E5xxcBWe3dB8d7DmbGbis52LAal8seexxFJRy8viautM 4TubylvXh6QveZdtWPkd8iKhNzctecb529S4IyOCgsVmhnqDy8JWRX7AwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-5.tower-94.messagelabs.com!1518030189!180663818!1 X-Originating-IP: [216.32.180.48] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 85159 invoked from network); 7 Feb 2018 19:03:10 -0000 Received: from mail-by2nam03lp0048.outbound.protection.outlook.com (HELO NAM03-BY2-obe.outbound.protection.outlook.com) (216.32.180.48) by server-5.tower-94.messagelabs.com with AES256-SHA256 encrypted SMTP; 7 Feb 2018 19:03:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qc5H0OFvRKtBRzat0N1xQQGNpcbEzXKFmnPKLHMHrRU=; b=PiimjhZolXz6Ar9/o/Rt1suyjklSneMHeUxMvgeOVnOkRoXpIpobhSftshKHkJB3yXv9w6sE1Ouf6uumaO8bDCPSz5Wzq6tVMrY1OD6Fp9LygijSXiyg4INqUDmRQEDX1lvVAXikh1UpCez45O/TQx3Yz1lcrOetAZMQGD7w2JQ= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1117.namprd14.prod.outlook.com (10.173.101.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 7 Feb 2018 19:03:07 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([10.173.232.139]) by MWHPR14MB1376.namprd14.prod.outlook.com ([10.173.232.139]) with mapi id 15.20.0464.016; Wed, 7 Feb 2018 19:03:07 +0000 From: Tim Hollebeek To: Martin Thomson , Yakov Shafranovich CC: Ed Overflow , saag Thread-Topic: [saag] Best way to store digital certificates and/or signatures in DNS Thread-Index: AQHTnuUFEnAVgGHXBkWYnq7Ag4jn/6OWjcmAgALAuXA= Date: Wed, 7 Feb 2018 19:03:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1117; 6:aSI50md4ZxWjUS3FmrAxmURVcFiD0lf1ZWkbWa+4qsuKAJrSQaGFo9u6LPHrVAOCd5Y7AErY/Dprt450O34rXTnRKNHhE+zEURdE/9Vzwsgindjr1tCK45y9rm6CtChrLtYLKU26IEmo327yr7NUNOgxALCOp2Kloq4j5//inG1j4cZBNxk2mpsAKuc0xTS5ojrzQJHwZQNZtRbdo5Qu7njZJaHJh7JVHcdKaDILdf/alDmp6oSouYGlHVNAO110Cico1lXahbn9qTcZprRkLqvDOazAw7k5oz8trwmLiz0o9BujPrsl24D19660Rtc2FIITwp5ZbMdc6+A696rypTHzEMkG6KL1Bb4Jp/9AReb7lscb/Gw+sZsLYNk/eB9U; 5:9HIbwiPYm6qzYFXb9GABCWpZ5K63iI5il2kk9g8Z6bwrwA43f2FlrZ9zXoTyB4+cD814Zid3bWGo9FOai/N1goYk58PPFX1zZPA1b/B20DpEeuLqJRVihvFirTWYL8+cwXTUllaa6oVM79J5FNKXVpbA32IC815sZKgYuZXPoSI=; 24:q4+Jv7+QaJTouLoNK2XeIeLQYOL3PNL4cbSfrLp5Ltyzyq8oFJlADvA05y/WOL0q8gVViLBbKvrY+7usAc8wuNTeCLpe3KhbFhZwtay+oS4=; 7:drJ1xYY/2F0u/xuy0HFMoQL1oO/8FitvFcK7CjwvQ1vUbQ9xKW9R/6XmrZKVIN2ukC0NrecE9tuW/DEoO9iGbWmrPc3fPVIKlFwOzf+6mtVvQtwAbosmekEW+bndMN8iRsNjh367KODdpY/9a7TUU6Kb8M4g63N1UbrlOq+ZUhAh+JdQrm7JWL/9d5t1z0knoadtsGwTF78loVHZRLlE/zESKZxeTNDtndjI+hwKdGfxqMM63NAMY+OnG3lzNjeS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 85863fdd-77a6-46c3-45ae-08d56e5d6cb7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7026125)(7024125)(7027125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1117; x-ms-traffictypediagnostic: MWHPR14MB1117: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:MWHPR14MB1117; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1117; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(346002)(396003)(39860400002)(366004)(39380400002)(376002)(199004)(189003)(13464003)(7696005)(77096007)(2950100002)(68736007)(81166006)(59450400001)(105586002)(81156014)(8936002)(8676002)(53936002)(55016002)(9686003)(2900100001)(229853002)(76176011)(53546011)(6306002)(6506007)(66066001)(86362001)(4326008)(6436002)(106356001)(74316002)(316002)(102836004)(99936001)(305945005)(110136005)(3280700002)(26005)(7736002)(186003)(3660700001)(25786009)(5660300001)(39060400002)(54906003)(97736004)(508600001)(14454004)(6116002)(99286004)(33656002)(6246003)(3846002)(2906002)(966005)(43043002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1117; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: SSpp/VsG39us3IEwNuALNL4JrU20y33cIWaN6KLpwo9Cbmb7nBf06/xfcme9fnqu87eOpupNguvnfjibYMM2GQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_05EF_01D3A00B.976E77C0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85863fdd-77a6-46c3-45ae-08d56e5d6cb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 19:03:07.6976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1117 Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 19:03:14 -0000 ------=_NextPart_000_05EF_01D3A00B.976E77C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please do not abuse CT logs for non-certificate purposes. Doing so is probably the fastest way to convince CT log operators to be more restrictive about who they accept certificates from. We don't want that. -Tim > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Monday, February 5, 2018 6:00 PM > To: Yakov Shafranovich > Cc: Ed Overflow ; saag > Subject: Re: [saag] Best way to store digital certificates and/or signatures in > DNS > > Have you considered formatting the signature as a certificate and submitting it > to a CT log? That gives you an audit capability. > > BTW, I noticed that the draft says SHOULD for HTTPS, which is a much bigger > hole than this. > > On Tue, Feb 6, 2018 at 11:53 AM, Yakov Shafranovich > wrote: > > (This is related to this draft: > > https://tools.ietf.org/html/draft-foudil-securitytxt-02) > > > > The proposed "security.txt" file has a matching optional > > "security.txt.sig" file. One of the common issues we have received as > > a feedback from potential users is a need to safeguard against the > > possibility of an attacker compromising the webspace of a given > > domain, and putting their own "security.txt" and "security.txt.sig" > > files there. This will result in an attacker now receiving reports > > about potential security issues in the compromised target. > > > > One of the proposed ways to try to fix this issue is to use DNS as follows: > > - to store the digital certificate that was used to generate the > > signature file > > - OR to store the signature itself in DNS > > - OR to store the entire "security.txt" file in a DNS record instead > > of being accessible via the web > > > > The logic behind this proposed solution is that web space tends to get > > compromised more often and easier than DNS for any given domain. > > > > What I am wondering if there are any currently best accepted practices > > to accomplish these goals in DNS with minimum disruption to the > > Internet architecture as whole. Possibilities I was thinking of is > > using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT > > records like DKIM and SPF. > > > > Any recommendations, suggestions or comments are welcome. > > > > Thank you, > > Yakov > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag ------=_NextPart_000_05EF_01D3A00B.976E77C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMjA3MTkwMjU2WjAvBgkqhkiG9w0BCQQxIgQg0WQNUgFknCihrPAbo2xLxEcvta/u o23Cp/J98sUHmQQwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAKULJoSviPRC/rkGpNWTdfl5hzRUXNXRBLSmvsylc1rneyyERiIUmflPaJla9whWBkHjHtGr 0jribDnXoeCD+i+2xZtnNlvCEgqGTQRdnajswBRMa9vOZCgkrAp9MEHs5Oi61TJiP8TPE/WGaAjw r67YmP5G6XwRlYpYsAZaCBcOMeuvxsPKbCc4olzcaS3YJKlP/D5dw8eDz8kd4RC/XkrsqBqVT8Qt pB1dWy3cFwxQi5QRPuPk7OA94xFtz9IDWUnd0EHNGL4G1UYpRw5jG3NCM4uGDX+4ICByygrMLJj3 i2TIskd+dxuV7hbFC6vbUhRW61IT4MOpX0ab5VNyKKIAAAAAAAA= ------=_NextPart_000_05EF_01D3A00B.976E77C0-- From nobody Wed Feb 7 14:46:11 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC1F124217 for ; Wed, 7 Feb 2018 14:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 P5KlucXGIcmV for ; Wed, 7 Feb 2018 14:46:06 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 3F35312025C for ; Wed, 7 Feb 2018 14:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1518043566; x=1549579566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UVOcUmOuIL1dIXRtURt1UeqgMuVixGTNEeSDyg1h6ws=; b=WaPKqpLdUI7NtGF3OqbuG/VZTW/7LyAfXveR5mWCsNoCvUSfELoO9aBf GkEumaQf1atuo3cBkWh9c5RKQekjajltuu5g7OEhl9JyU5a/QUYwejQyL SdlI1meNWO2VPIKeIXpZxopMeaeZChXJ8QY/y2cUcaIwdMIb77zg0QDHf RwIB3tPNPutgWNR1hkZy/+H7IkAzQF10foJToQU4NK9w9m4z51xykYqGd +W9e2QzN7pN9rxlC0HeqLrZn0BcuHj9di7o4vFw2l9T1AstZKG9dncki5 OCoxS48qfybazi3EH13ywikHF0dzIf1h8CC7rmZmDBG4/PnoGwxKtnV+X Q==; X-IronPort-AV: E=Sophos;i="5.46,473,1511780400"; d="scan'208";a="786011" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Feb 2018 11:46:00 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Feb 2018 11:46:00 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Thu, 8 Feb 2018 11:45:59 +1300 From: Peter Gutmann To: Tim Hollebeek , Martin Thomson , Yakov Shafranovich CC: Ed Overflow , saag Thread-Topic: [saag] Best way to store digital certificates and/or signatures in DNS Thread-Index: AQHTnuUHHT5SNHmYy0qSuDhOaZnm9aOVs9uAgALBAICAARghjg== Date: Wed, 7 Feb 2018 22:45:59 +0000 Message-ID: <1518043556659.74272@cs.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 22:46:09 -0000 Tim Hollebeek writes:=0A= =0A= >Please do not abuse CT logs for non-certificate purposes.=0A= =0A= Exactly. That's what the Bitcoin blockchain is there for.=0A= =0A= Peter.=0A= From nobody Wed Feb 7 19:22:02 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A662812D82E for ; Wed, 7 Feb 2018 19:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 Pbgg9v_iBAhW for ; Wed, 7 Feb 2018 19:21:43 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 803D312D811 for ; Wed, 7 Feb 2018 19:21:41 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id r23so2885879ote.8 for ; Wed, 07 Feb 2018 19:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=67oh9mYedgNb4E6RRNLCFeJ1QCgSBdWxkCp6ARH2Fyk=; b=TEtB6dv4pczaxQF16ywlD/MlZRZTaSmpIakuosVNrs78mVrN78y9EFxaJqX6zetm5k 8JzM3Fx/lneZBqTFjMljZD/Dhc2ULlRG/peCU/aCjPlGNlwKABPbhUAJR4dYxDclf4iD LpRPhbOoynYw4ZcNR3EGnnFmIZ1viuxKRJVj3JYGde8YfwU0sFI88ZeGSwpRmpXNQS6Q R9CXjcsSogFZZWVN6qDEoFtIzaP+M3WK3As5cnUbKxJIJpaY0Gt8iqZMEM0jGMxMLWZA N61Zdmz7DymT8CYdsdDM0yPnKUoO4XclUPM50+Q6JbsqXKfFEnxmSvrlfxsKjT41ZZDk ukCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=67oh9mYedgNb4E6RRNLCFeJ1QCgSBdWxkCp6ARH2Fyk=; b=fIi8Q+xr4tRJOAB3VzJqtc5hLHQfiSveId1r+eUBpNBjY0lMYFRzvk8Il+jTi7rzQV f/bL3nVRmbq8S0f0eCXHM3WGlGR5oTz48QlYsGBsjlJmVsch50aDZ255CwRsgrYHy6rX 4RGSS3oITbWKM7O+ZCqHR9JnhgfMkElLrBFIWc6Op6dng3GmQf9H3wVcYU0ThjAusroP cSW3uwGJEksJG70YlgHw4dL27vdQanxoTyFxmZ0ZCNmDk9VoGssmlVZKWHIz640JeL2q mjk+zdDsMnKoRW8V4MMaPt9NVmmXn2XEJkDlxkxBjE73riuFJv6Cp6KiLW54R5pq/kph 64YQ== X-Gm-Message-State: APf1xPA0hCZJERfwHJUoJftzZ1VQ5FVBvx3BIrvYG9br2qh6LLKBAVvd 62Xvsd053CPmCoWAh1o6BYjZ6zq7Osg6yeD+13QUMg== X-Google-Smtp-Source: AH8x2262+H5VKh3imwLGSAe+jVjFgru7Nnc0tYciKUvp2xeVcRSC+8n4cFit6MsL+BxmeONqf/H90h+H9dwBr5LnS3w= X-Received: by 10.157.59.8 with SMTP id z8mr6446506otb.45.1518060100791; Wed, 07 Feb 2018 19:21:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 19:21:00 -0800 (PST) In-Reply-To: <20180207154541.wgr7mtmwx2yymnd4@nic.fr> References: <20180207154541.wgr7mtmwx2yymnd4@nic.fr> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 22:21:00 -0500 Message-ID: To: Stephane Bortzmeyer Cc: Martin Thomson , saag , Ed Overflow Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:22:02 -0000 On Wed, Feb 7, 2018 at 10:45 AM, Stephane Bortzmeyer wrote: > On Tue, Feb 06, 2018 at 11:59:49AM +1100, > Martin Thomson wrote > a message of 44 lines which said: > >> Have you considered formatting the signature as a certificate and >> submitting it to a CT log? That gives you an audit capability. > > I wasn't present at the beginning, but it seems to me that the entire > point of security.txt was to have something light-weight? If we need > to set up CT logs or blockchains for it, doesn't it defeat the point? The intent is certainly to be lightweight. The level of effort we were targeting originally would be the same as required to put together a "robots.txt" file, which also explains why the syntax is similar. For the DNS piece, SPF is what comes to mind as an example for the level of effort. As per Randy's proposal in the other thread, putting a hash into a DNS record is probably around the level of effort targeted. Thanks From nobody Wed Feb 7 19:26:37 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66DF129C6B for ; Wed, 7 Feb 2018 19:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 47CVV1ENzi4E for ; Wed, 7 Feb 2018 19:26:33 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 C5DC3127342 for ; Wed, 7 Feb 2018 19:26:33 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id h14so2898306otj.5 for ; Wed, 07 Feb 2018 19:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LI/WFaF6kIonYUtvBzuc8UtCUguPJLj/gqkS/sNDPyM=; b=cBQkSYkFhVKmoIDeN87KPZmVf8l72tKgrWQRL7qRbxl445JiLRNauC+5Yzl32fHIu/ HBA9n5NDKvDBGGLoqj4W6jWQF0w1dBeKRse8BQ0rc1wOA//9EhKKZ7GSwxadSXRKNf8a vTCnOir0gAFUVIdqzUrT9X6XVEzgqpGCgyJ+gnbp0eqLSRmkPgiBa6Ck6xxO8T7h6EBP rW34/GdRag55/Pc94EyWHU0FMsSsYRGGeci9NpTQkzjG3Tl4YjFQxtuhYKIGXPo3Pnns LSqQk0JZsAt0gSb93977Axq7VfsvVd0JdFIrQPFnOUAp1OCa4inpi4Kb6K7uthyqoRgD zf/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LI/WFaF6kIonYUtvBzuc8UtCUguPJLj/gqkS/sNDPyM=; b=NHCwaQ2ZOVAzskseiAquR4+VOzNSMj9VR/sgny2L49O6B970FCq/WSdqNKlqowkkwe pSkHSSUn9oEZmLWdxvuk5jJc+jMmS65Ly21XNx9KoDsscdEdsYmlL06uT2aB2bpTfPrh YuJijRNvYWr+9X2Sa0HRVeAC2TPvJxd3H9Bg2rxDWcgweP7aswdxZU9Wb+te2G/pfS/7 5gBaoYUI1iJqVbB7Kk+JptqwUurEHw89ABIfQMlulvyTNHz4pX+Dygl8Zh5+igEseoLL JYywgMM2oj+Fv7i61QKrZZVovcrmUxAiphk9QIE5Uu676GjJAvlt5AqfjC0TBBtKN3+x RdVQ== X-Gm-Message-State: APf1xPCaswxbP+q6I9JZdUecdCIjKdjcVfSO2pPdSC3iR6IK5g2CAm3J uWshwXXprUJilE7xSnqYa91TqavxxuIq9Y+c21hRWA== X-Google-Smtp-Source: AH8x225vW5G70wf6zqyl3R1pdUwfyuoEI9dFjObms+bvS27KVvRSn9VDQ81OlfPFYmLtOsjjbcgFJDKc1OPKAILRk2o= X-Received: by 10.157.80.10 with SMTP id a10mr5769385oth.147.1518060393005; Wed, 07 Feb 2018 19:26:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 19:25:52 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 22:25:52 -0500 Message-ID: To: Stephen Farrell Cc: Randy Bush , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:26:36 -0000 On Wed, Feb 7, 2018 at 5:58 AM, Stephen Farrell wrote: > > > On 07/02/18 10:29, Randy Bush wrote: >> contact schmontact. just stash the hash of the signed sec doc. or are >> you trying to subsume the whole enchilada? > > If the person using the contact information kept > history then sure, ct wouldn't add much. OTOH, if > ct keeps the history then anyone can go find it, > when it's needed/useful. But the ct-angle is just > speculation for now, 'till I or someone else goes > and tries it out. > If I understand correct, it doesn't have to be CT logs per se, just any kind of a distributed system that would keep monitoring the security.txt files and keep state in some fashion. So even a Internet-wide scanning service like DNS Trails or Shodan, could in theory be sufficient - the question is whether anyone would be willing to set those up and run them, just like we do with CT logs today. A member of our project put together one such service here as a prototype: https://registry.securitytext.org/ Thanks From nobody Wed Feb 7 19:30:23 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DF9129C6B for ; Wed, 7 Feb 2018 19:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 FgZGoCmMrYIq for ; Wed, 7 Feb 2018 19:30:20 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 5FDDC127342 for ; Wed, 7 Feb 2018 19:30:20 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id f18so2903701otf.6 for ; Wed, 07 Feb 2018 19:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RuJsqqXSCRC9354a0iNFqOOu41VsgMBaqh1mKi6lPzU=; b=Z9u7F19Bri+6ADxO+WA95+KaK0uGqdKJoy09M2d8k/60Roer/Jwr0PGtpqD4XwIE2D NCepmEOzIaMMRGQGM4Ug98EvQ7F0I+9Ful8pxjicl6OItsu8O/6BP0e9vce2/R7LOkG3 Ed22u8o1eJX3S6Ywi6qXZr4U2XhQvzr0NDrFgxQmYggp4nPKxuinNQD7MXnFD63YnSgu SbL/NZyrp4cgRg6YrR1MGAnKbCxPzoNtFolVE93KOKs8n/w7Xrm3aBXK0B8KTLifPtPD X/W3Zu+lCjU2WwamFrfpyFFxSO5xlZdUdZG0cE4L+4DdO+3gaBrn6CENg8vt14Uee7gu NAAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RuJsqqXSCRC9354a0iNFqOOu41VsgMBaqh1mKi6lPzU=; b=Q4HFs4QhmVf2Le1l9sYghBPATc2vY79gpaT+uot4s/V+6+outzypyIstcnKPRMP5c5 kaUzgu2C5pHt1+fdrwWPooY/YQPCeOjnQdIiCir653WZLUH/KPvfx6RnFJ7s4g/xHjG/ BEGOrQuYeL0rjJ9BzPn45UBcyiAde8EphhmzG9gu0ru6i5o98YuPWtzTmfxWTgutPx3q NKqcHT2U+h/kZf5nsVcyn6wOjX3Qpg3Ing1ydaHnmFNgjRL084Gs0dpZnP2FCPErUHP9 cO2Iksb1WF+Vu4yPGxEHYZhrNQ9TA0w0jxhTak4X2EIetexse3RHNtZXEtekCOAn0dMY 5rgg== X-Gm-Message-State: APf1xPBisMfEIjz8PM7zmoEy4mhNEH0HUHvQqES6OJa9riy6Tuyz3nII GkQa8gGAW+rZgUk99wga2POHZO7xb7hVRICTtG139JZW X-Google-Smtp-Source: AH8x2278ddh6uPPu7PWmpINODwFfsfTagtA0kYJTkHl/WOYK3/z0vqSWYhcfHpxL8d+jm07yyQ3Jl9Pohl0BPJzbDdk= X-Received: by 10.157.59.8 with SMTP id z8mr6457960otb.45.1518060619702; Wed, 07 Feb 2018 19:30:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 19:29:39 -0800 (PST) In-Reply-To: <20180207154045.dm2yvecrv4qz3keg@nic.fr> References: <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <20180207154045.dm2yvecrv4qz3keg@nic.fr> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 22:29:39 -0500 Message-ID: To: Stephane Bortzmeyer Cc: Randy Bush , Rich Salz , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:30:22 -0000 On Wed, Feb 7, 2018 at 10:40 AM, Stephane Bortzmeyer wrote: > On Tue, Feb 06, 2018 at 09:26:21PM -0500, > Yakov Shafranovich wrote > a message of 21 lines which said: > >> My question is really around whether there specific guidance for >> subdomains like these in DNS? > > Yes, RFC 5507 and 6950. They are long documents, so here is a one-line > summary: > > If you use TXT records, don't put them in the apex of the domain but > underneath. > > So, _securitytxt.example.com but not example.com. > Thank you! And I assume that underscores are preferred as per RFC 2782? >> An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature." From nobody Wed Feb 7 19:32:01 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A369126D45 for ; Wed, 7 Feb 2018 19:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 3VY7gUH7ljC6 for ; Wed, 7 Feb 2018 19:31:58 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 9DF181200F1 for ; Wed, 7 Feb 2018 19:31:58 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id a7so2901545otk.9 for ; Wed, 07 Feb 2018 19:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UcN5EfIyqcHX5uKo/38vmWkH/Ir+0TTLMzk5V3ZdG60=; b=pXkgDhEygz/kADpvTJ/eNHgZ/Wafcn/UIwA+kzv0p/BJAcd2GmGqXZPopgj/tX0z3R MwSZcLv1QrgpgeraRImTK2tBhSUmWfSSgvrBMdfTeIOc6jwyhThTUu0ss1OxY7Wky8j3 Uop3GKDbRmLUmZL383pYzbyUHbX+4k7yMnc4kOtO8uSNhHojAjCRNwRqIzsY2iIlG5gY FI9SzIq1V8xBrrLjWiKHQ7xH1xFqTaMLbYAMjU832rPu7ROXONnUf9FsFE9yNFNVVKdt PQa27/vV0NdWL/JPUYfowdHBf7uCk1UZMuxrJjkueLzyiEoN4Pi6CFkBePlghumo+5d1 8iBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UcN5EfIyqcHX5uKo/38vmWkH/Ir+0TTLMzk5V3ZdG60=; b=jvdfRomuOJjs4Nheg0EH9Int6OlxA9fIrgETTh9a7GcnwdYMcx2eHAxDeqDoQkO3qH Mme6HwymMJbFBQ8kNzq7pYOmb2gYDSocbElPm8S6svm/wsXgKSphLGuZD3KPM+mhSubN 6oix8b6nnW0dlnAcobgYOFML7SVkkCibTba+/FKbN1asNeCTxvnVJw9g3RQBufUDEIAT RhYddLEB2d6zvDgNTC5huYbjtBMQrUuI2LqOmtQayhP58Sep4lLKnphUnKM6Hvx6Lb/N vizM3Cx3JGv7Gt5QUiHOXYrDWvkyJSM3rTDMbHB0kblrLyrK2W8u0T4mjdAKXeE8Y1a1 qOGA== X-Gm-Message-State: APf1xPDSwBIIc12zd1lR3idMpmfHXzdTf1VL+mKnclYJW3OpQ291W25p X8j1LOh/hhnp41/fToNX1AQs+p07zhb5FDu+YMhs+g== X-Google-Smtp-Source: AH8x224m7hdpXcW07xMmDXJiQBsRLQsS6WYqX21JewGo2rV8y7OuE5Qnhar2QwDfy8BilCodHIm337ifpob21Ux4EQ0= X-Received: by 10.157.80.10 with SMTP id a10mr5775603oth.147.1518060717977; Wed, 07 Feb 2018 19:31:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 19:31:17 -0800 (PST) In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 22:31:17 -0500 Message-ID: To: Randy Bush Cc: "Salz, Rich" , Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:32:00 -0000 On Wed, Feb 7, 2018 at 1:10 PM, Randy Bush wrote: >> The one thing I would suggest is perhaps placing the SHA-256 hash >> under a standard name for the domain or subdomain where the >> security.txt file lives as follows: "hash._securitytxt.example.com" or >> even just "_securitytxt.example.com", and the hash would be in a TXT >> record. > > you seem not to have read my message > > % dig +short security.txt.sig.rg.net. txt > "fa1dce4207c0087d19d949bb600613fff2bcd2933e76749afedcb8e5500e70a9" Hi Randy - I did read it, what was confusing is the lack of underscores that I have seen in other cases like DKIM, DMARC and SRV records. It looks like that the use of underscores would be recommended in this case as well? Thanks From nobody Wed Feb 7 19:36:02 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC90126D45 for ; Wed, 7 Feb 2018 19:36:01 -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, FREEMAIL_FROM=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 7geIdycFhe9z for ; Wed, 7 Feb 2018 19:35:51 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 1518C12D7F1 for ; Wed, 7 Feb 2018 19:35:45 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id a11so1165172pgu.13 for ; Wed, 07 Feb 2018 19:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=QLo2iywjw0WuH1+u4bKHW42/wG1Zny3Z15LdFdMsZLk=; b=TzR/Zq0r8NfCUVRu5XLPJPqcLCpCixFagmKWyFcjihovGcSmdBC85wTaRWFcvJqvIw mpgwAp1xJ2aUpdAl+sLGp1btHPHMNlIyNp/gOYlXxa2BDlzBjMEFDMybD/ysuBFJrV8+ s5gwiV6oEjyfokMI0lcj2p5VZzeDZs83a6GtHHwH6gq9R06ExIvDXKWlBZVtvQhbBkZs W3xA1XYyAjEQ+PSMqyyXkddfvaSMB5OxkjgbVDKDy1hB3HzHEIln4NzMwYMGgYodZ4w8 PM1cfZV62szzPt9YB7LI/+uHky6CzdhjliV0keUZWXvuSjcNLnQ+4m5p2cSdIN1NNyR0 /pDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=QLo2iywjw0WuH1+u4bKHW42/wG1Zny3Z15LdFdMsZLk=; b=U//IgzsFNtuwKAWs2oXav2puJZjz1q8jGAs+VJrBeJWENsyz0ll8mE16NrqHreZ1ej wSsV/NEkgPYWqV/FQRfjlCMCsofgXGSRFf5lgXZCwP+LGx1wttiw8mE0qty/pggU2Tfu pzOfSLQsevAJY1kmKYtneaaY1bObKkLCShN8TUgPMvwKpV+jGVFjqdZQ1ZVVxZUcLHID 7M3ahRNvEW6qavqsb7xOS6CaeSRXHcGmjZKIedpq4a3aNcM4NX8yzAaGbb1eJkygnMzc CAlBLWGyn0/zNunz9Mbzyta/pcOlhwXNyBpCRofU9SDGpPyaKSRLuRuUirE2zbw4WbKW rhUQ== X-Gm-Message-State: APf1xPDOFfuoLjD0qT/c4NZ0ArzuxTX9sdJDwUYxeYf2MtvZ5TvHTt4K fBi377HpxRAs5eULjsjqkkQWFA== X-Google-Smtp-Source: AH8x224IdSkaMIHGXHRGr2oSvHyzqE2Ia+GdOuX+d3nCPsPpqGOyUP8IZAmLEYA1KPAbVdvGLt4jNw== X-Received: by 10.99.103.129 with SMTP id b123mr6569791pgc.177.1518060944182; Wed, 07 Feb 2018 19:35:44 -0800 (PST) Received: from aspen.local (63-140-68-28-radius.dynamic.acsalaska.net. [63.140.68.28]) by smtp.gmail.com with ESMTPSA id k3sm6538963pgr.12.2018.02.07.19.35.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 19:35:43 -0800 (PST) To: saag@ietf.org References: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> From: Melinda Shore Message-ID: Date: Wed, 7 Feb 2018 18:35:40 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="S38RzjDaEv8ixpeXeserXc5SLvNI8Y8WZ" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:36:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S38RzjDaEv8ixpeXeserXc5SLvNI8Y8WZ Content-Type: multipart/mixed; boundary="U6CVtsbfYKUN4UAXHT8h8CogghtZVJT37"; protected-headers="v1" From: Melinda Shore To: saag@ietf.org Message-ID: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS References: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> In-Reply-To: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> --U6CVtsbfYKUN4UAXHT8h8CogghtZVJT37 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/7/18 7:01 AM, Paul Wouters wrote: > I'm working on DNSSEC transparency, hope to have something for IETF 101= that > resolves questions raised before on this topic. It's possible to do transparency without having to shove stuff into CT logs, but it does mean that somebody is going to have to run log servers for whatever application is being transparencified. FWIW it would be possible to build something on top of Google's Trillian, although it may not be what these folks want. Transparency logs have some properties that may or may not be suitable for this particular application, but in any event I think it would be helpful if the authors were more precise about what problem they're trying to solve by storing digital signatures in the DNS (or transparency logs, or ... ) and what properties are required in a solution. Melinda --U6CVtsbfYKUN4UAXHT8h8CogghtZVJT37-- --S38RzjDaEv8ixpeXeserXc5SLvNI8Y8WZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJMBAEBCgA2FiEET2gtkyoXlvgg8jTA37iRcpp2248FAlp7xY0YHG1lbGluZGEu c2hvcmVAZ21haWwuY29tAAoJEN+4kXKadtuPhB4P/jPFv5DNdONICfLQA5YtFpiO wzIT680SWljqHUqMJLOMJSjFZ+vXbihH6/H6SAqkAYMKFZwXAmuAhar8TCo2modd smEly9hMdwU7xo+YENFTVS75v4EVYz98Uu1LHsEKFp2U/e+vGXa8Sv2GhyFeS+I3 eNNKBcL4qx7r55VDW2oSDmIPnmOgMHR3VNzdTtaW8opQdlPRpGmHTi7DkG5Wc1/a KXr3mMfzKHUP11+pHEe+2nq2JGUxjJoa8tWqQTWFqLT+Hjk7XnTGvJSaDbAi1lbC KiypypP2rl2ZeEX+kx+e4rgpkV2TnQdYnaFNXvQWbL6WGVtUIDBUnVK4r68Lqgql 2dLBIzusmvCsAeIJ4GVS/wAxoapnhld7ULwaYUHlDeoOC9hrkOrPULXZqgBmNehk GeR/Wo5NJKKjY9KwUeqxGfQxkAYVVdnYbEVoq5R4bWGU4Cr6I9+SJkGr5BrXislG fd/vseFwEdqo9PDAcCFiNX2ChU0sFVl4WOPFSfYVQwag6mTl0r6ZVFFMJ4GOTOSh aZ1FzYJIspw9VFx9jsVoDwcZqyF0UxUgv1MVi0A2yyWYKJUuN89Gh4gq1aNas2lv DZJLhnFgkls38FZ4S94N+0N6ia/8poh5hh3s/NzhO4OFUCZgbrTlktfb1/RguYBL 0zd55f1fwKdYh4c43u8v =CIzh -----END PGP SIGNATURE----- --S38RzjDaEv8ixpeXeserXc5SLvNI8Y8WZ-- From nobody Wed Feb 7 19:37:06 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9F612D7F5 for ; Wed, 7 Feb 2018 19:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DJMXXPJBzwZt for ; Wed, 7 Feb 2018 19:36:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 0ED9C126D45 for ; Wed, 7 Feb 2018 19:36:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ejd0u-0000VJ-JX; Thu, 08 Feb 2018 03:36:44 +0000 Date: Thu, 08 Feb 2018 12:36:43 +0900 Message-ID: From: Randy Bush To: Yakov Shafranovich Cc: "Salz, Rich" , Security Area Advisory Group In-Reply-To: References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <963A92E4-5B7A-48B7-897E-E3ECC8F418C0@akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:36:54 -0000 >> % dig +short security.txt.sig.rg.net. txt >> "fa1dce4207c0087d19d949bb600613fff2bcd2933e76749afedcb8e5500e70a9" > > Hi Randy - I did read it, what was confusing is the lack of > underscores that I have seen in other cases like DKIM, DMARC and SRV > records. It looks like that the use of underscores would be > recommended in this case as well? avoiding guilt by association with DKIM, DMARC and SRV and don't actually care randy From nobody Wed Feb 7 19:45:40 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB3512D7F9 for ; Wed, 7 Feb 2018 19:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 By4fDinVdQz4 for ; Wed, 7 Feb 2018 19:45:37 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 4C06712D7F6 for ; Wed, 7 Feb 2018 19:45:37 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id f56so2910785otj.13 for ; Wed, 07 Feb 2018 19:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mbRQlZickItoFehbQjfisEn8F7KdnxDm+lyBBZU36zg=; b=fFFnOpi5QUxmNUDSc/6YYwV9nFsm+qET1MQAdfdWKttgyVAp0Cu00Zq0gEJ10NqbHn ZaNRLgkrqz6Y/Z5LhN2VThPDf919ns4vwVQCKOUlv10QNZK+KpFko1WHuRNA4/vTi24F jYJooFAl5LEnAbnp/EwjWnsCrSv/o0O9XHiHTQCLsVpPkhIa2isXAwVLM590M4iI77bu fnoRF3sW2HP8hvNiWFbL9cnLfsR6F7pwtpp7htTgiza4UzTREsazux+G+nsbz6wajgJR /e2GzdoJDUJaF6P7y7Ulk/NWoP1f4yIPKBemGHzjBSSq6usRk0T8wiJr5CVph9L/GHpL gTmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mbRQlZickItoFehbQjfisEn8F7KdnxDm+lyBBZU36zg=; b=jKLy3gtGfhLtPt526HJ6aAtzd2ASdzfsZuWEGJey6tBW9Pnv2D3YOzRxDk3+iLZyia 31cP+5QW6+ivhXE2P9+Rc4yLI0JbqxxXd3RB80zmzWWg+k8SFNFHcAmhthwPsX4RpQKA AQ90oLS9vlV6S+hFBZlvHB6E1ggEoLUrEjeVLTx/yJm2DlCAsJH/arIbRlwDT9BKaWAF BsNqaTub0E2zkHk/8vaamQn6+OxZWAVZyMVJkJ/2jjas0VpuZwkzlW/uJZey6mh1SdkN UDTA3y+2mJU7uLT4ep6nm2D1Nm2/ARmEBKdk92cKp6amPG9jCOjD3by+ua8Gy9sGOuoc IDug== X-Gm-Message-State: APf1xPAkrnfSn+C8QagFFwWysVek/Wu3hDJC944ioScjYmvOT7W0cn17 veIq0V4962846wJ6qnM+1a4CMSa8hJGrK0VoZh152jNrs58= X-Google-Smtp-Source: AH8x225aBf1X2oCEAA5sq7G5JhB8kLqMoioZ6dEEivnAFTl7F+hwKCIgM+0pk41HXVpFO5f0HWMBzKS5jshDLxbWvCQ= X-Received: by 10.157.48.65 with SMTP id w1mr6692152otd.391.1518061536595; Wed, 07 Feb 2018 19:45:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Wed, 7 Feb 2018 19:44:56 -0800 (PST) In-Reply-To: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> References: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> From: Yakov Shafranovich Date: Wed, 7 Feb 2018 22:44:56 -0500 Message-ID: To: Paul Wouters Cc: Martin Thomson , Ed Overflow , saag Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:45:39 -0000 On Wed, Feb 7, 2018 at 11:01 AM, Paul Wouters wrote: > >>>> What I am wondering if there are any currently best accepted practices >>>> to accomplish these goals in DNS with minimum disruption to the >>>> Internet architecture as whole. Possibilities I was thinking of is >>>> using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT >>>> records like DKIM and SPF. > > How many times can the WEB depend on DNS(SEC) without claiming it is not depending on it? > > If DNS is more trustworthy then content served by a webserver, then why not store the security > contact information only in DNS? Like SMIMEA or OPENPGP records for security@domain. > We do have an open issue about whether it is feasible to take this a step further and shove the entire "security.txt" file into a DNS record instead of serving it off the web. Haven't figured out yet on whether that would break anything: https://github.com/securitytxt/security-txt/issues/35 > > So, if we really want a standardized way to provide this information, go do this in RDAP. It does not depend > on the zone's DNS, does not depend on a compromised web server, and its format is meant to be very computer > consumable. > > If that is "too difficult" for admins to do, then maybe security isn't their thing to begin with. > I am not that familiar with RDAP - are the RDAP servers run by TLD registries and RIRs only? And how would this work for domain admins - would they need support from their registrar to put the info in, which would then feed into the TLD registry? Thanks From nobody Wed Feb 7 23:29:35 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980C31200E5 for ; Wed, 7 Feb 2018 23:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JRN95fuCM1xR for ; Wed, 7 Feb 2018 23:29:31 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 4B78012D848 for ; Wed, 7 Feb 2018 23:29:31 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 8CBDF28216C; Thu, 8 Feb 2018 08:29:29 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 85F1F282449; Thu, 8 Feb 2018 08:29:29 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 7F20428216C; Thu, 8 Feb 2018 08:29:29 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 78F8A61083E3; Thu, 8 Feb 2018 08:29:29 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 709B34068A; Thu, 8 Feb 2018 08:29:29 +0100 (CET) Date: Thu, 8 Feb 2018 08:29:29 +0100 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: Stephane Bortzmeyer , Randy Bush , Rich Salz , Security Area Advisory Group Message-ID: <20180208072929.ipx7yntbpje3eole@nic.fr> References: <733c4e3c-491f-623c-6438-9f1763f61f79@cs.tcd.ie> <20180207154045.dm2yvecrv4qz3keg@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.8.72415 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 07:29:33 -0000 On Wed, Feb 07, 2018 at 10:29:39PM -0500, Yakov Shafranovich wrote a message of 20 lines which said: > And I assume that underscores are preferred as per RFC 2782? Yes, because underscores are not allowed in host names, so there is less risk of collision. From nobody Thu Feb 8 08:51:44 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657341201F8 for ; Thu, 8 Feb 2018 08:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cRNXxnMZtMQR for ; Thu, 8 Feb 2018 08:51:40 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0541F12D830 for ; Thu, 8 Feb 2018 08:51:37 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A2160200A3; Thu, 8 Feb 2018 11:58:12 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 55EEE806C2; Thu, 8 Feb 2018 11:51:35 -0500 (EST) From: Michael Richardson To: Yakov Shafranovich , saag In-Reply-To: References: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 16:51:43 -0000 --=-=-= Content-Type: text/plain Yakov Shafranovich wrote: >> How many times can the WEB depend on DNS(SEC) without claiming it is not depending on it? >> >> If DNS is more trustworthy then content served by a webserver, then >> why not store the security >> contact information only in DNS? Like SMIMEA or OPENPGP records for security@domain. > We do have an open issue about whether it is feasible to take this a > step further and shove the entire "security.txt" file into a DNS > record instead of serving it off the web. Haven't figured out yet on > whether that would break anything: > https://github.com/securitytxt/security-txt/issues/35 I believe that shoving it all into DNS defeats the purpose. Putting a hash in is a good recommendation, but don't count on it. I think that the goal is allow end developers directly responsible for a web service to directly put their contact info into place. In a small entity, there was never really a problem, emailing "security@" or abuse@, etc. is easy as the developers can go one cubicle over and get the right address entered. The issue is with bigger entities where the DNS is entirely a different divisions' bailiwack, and just getting the right A/AAAA record entered for api.foobar-division.example.com might have took three meetings and involved a mandate from a VP. So the SHA256 hash might make it in, eventually. Or not. In fact, this even raises the question to me about using /.well-known! Consider enties like google or microsoft, etc. where almost everything comes in via "google.com/FOOBAR" and gets distributed by the front-end presentation tier to one of many backends... I'd actually suggest that if you want to report a problem with https://example.com/api/v2.4/redshift/blueshift/432, that you try URLs like: https://example.com/api/v2.4/redshift/blueshift/security.txt https://example.com/api/v2.4/redshift/security.txt https://example.com/api/v2.4/security.txt https://example.com/api/security.txt https://example.com/.well-known/security.txt because that would let the internal group put the most specific pointer possible in without having to deal with bureaucracy elsewhere. That is afterall the issue: the bureaucracy is opaque and often lossy and reports go astray. The goal is to short-circuit things. > I am not that familiar with RDAP - are the RDAP servers run by TLD > registries and RIRs only? And how would this work for domain admins - > would they need support from their registrar to put the info in, which > would then feed into the TLD registry? Yeah, it is intended to replace WHOIS/RWHOIS, which has not been that successfully distributed. It's common that RIR's have a pointer to BIG-ISP for some /8 block, and that works. But the intention is that BIG-ISP will then delegate to small-ISP some /20 block, and even to end-customer the /24 such that the info is correct. But, BIG-ISP doesn't want to put a list of their customers online, so abuse reports do not get through. RDAP makes the WHOIS data structured, but doesn't make it any more likely that end-customer's data will be correct. RDAP involved more bureaucracy than putting the contact info in DNS. I'm all for promoting it's use, but it will only be reliable where all layers of the end-customer are diligent and responsible. We'd be preaching to the choir here. What I think security.txt's goal is to allow a tuneful solo-ists in a discordant choir to be discovered despite the conductor attention being elsewhere. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp8gBYACgkQgItw+93Q 3WUmRwf/euN3oTqSoCeicBuGJvJJ1SpxSUqmrVyXJK+h3B73FZN6b6JooGxyNlEA o2gzCVFbaTA+Vmb74bwhSy5T4/CPtA4zngi0sI73nHyJtRQV8tK+iy0GeihiJvSk eNTjRX3u86yacRd9VcY4PRyXVXpOALZgUZqcKO63flgWNjXCbnivekSqcwbwRNUZ WTWjNdKR2glPMBkBWyyiBNdI70KVam2FSq4Ft7Pnstp6cWazMBkqIscmzbaU95VV J6H6mtoDz/Shz+GKjMP6DqyOemNMB5BWZ5OXTMTgzXIx89a/p0jsrAl5Tz4ad4s4 us8ykzyytMyJUZ3gVtuSBY905kZCJA== =05G0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 8 17:53:49 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF126124207 for ; Thu, 8 Feb 2018 17:53:48 -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, FREEMAIL_FROM=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 0f2BgddES8n4 for ; Thu, 8 Feb 2018 17:53:46 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 48998120721 for ; Thu, 8 Feb 2018 17:53:46 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id l5so6234002otj.11 for ; Thu, 08 Feb 2018 17:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RAC9MIwD56Sr+PrK9duWXEODpTm18ePORzH5HfUk3+o=; b=kwpv9eGaB/wlQWrdhHz60wEiofAeSMDp6lRcGCt8h1yjK0Dr38Td3B6TPMbVrYNofN fqjTV3YcUoL3nUdNzBcoUbA0YiGl4NcMcLN/1h84lt+TtDKQXUMLJwz1kMRuBlbs7+Gy 5SgyqzF0E4JYgNTSYZ3og8vBAZyzYUH/y3aTt7A3AeWxjAz+8OkHHghjROlcM0j2eVj3 6vFIUOrnfQKQj+5+5H/7abhxn/qtJd/EdhRXT1W4fZYo3nS20onROQY40bEKI64ILUQF 2SvqwU8kBltElnivsWw//JgDMd3ZJt0AE6Hxlo/zXITgVoH0yGGjWjR0TNayHZr8YB6/ j1Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RAC9MIwD56Sr+PrK9duWXEODpTm18ePORzH5HfUk3+o=; b=XsUE6G2uFWPjXpKBiN+6J0DTSpsXds34uDjhU5S85S9e7r+gCkbjgJvRfW66mpvydn JmZvNqO9cSlEdwVSSqeTfiat5azdnEK0F9sZQkmdcD4kSYtHrNy0T1ZQlAaTAc+6R39E PyUl0v/vKZkCSNSdFP2Fl/C1FhCnhBKAgSCH3ZBQj13fz2mXblogVsvgGcnyKnfrHSNC ioDdDy4V56Cx5M8oEYuKyFbjR4a9yPpWa8/J0yDsZLWqTwOsv/N9DAGxBWbI7B830mpQ DiLAX0pI5ois5QsxeVUfG0i9O0ygTyDJWGQOOuI6O8remd3zeqsYaMChe2qahm0FpX68 DFig== X-Gm-Message-State: APf1xPDAahTQW28+B16xpkISzgVfHGkaEADcpOeWnTXuve/uDvuPsrJo IoTbVj7JYzzK3Icj7Yw8zQsErh3qZ590JZHeDt/beg== X-Google-Smtp-Source: AH8x226S9FcmTwJIjWiLoUu+/WYD8S3Pf+YppoP6YJBNAoHmChC6yx9phJnOOOjPtBJKjrs19phtA/Ojfuzckv/eTk0= X-Received: by 10.157.54.233 with SMTP id s38mr973688otd.103.1518141225518; Thu, 08 Feb 2018 17:53:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Thu, 8 Feb 2018 17:53:44 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 9 Feb 2018 12:53:44 +1100 Message-ID: To: Tim Hollebeek Cc: Yakov Shafranovich , Ed Overflow , saag Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 01:53:49 -0000 I thought that this would be a certificate. Maybe one with a new KU bit. On Thu, Feb 8, 2018 at 6:03 AM, Tim Hollebeek wrote: > Please do not abuse CT logs for non-certificate purposes. > > Doing so is probably the fastest way to convince CT log operators to be > more restrictive about who they accept certificates from. We don't want > that. > > -Tim > >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Martin Thomson >> Sent: Monday, February 5, 2018 6:00 PM >> To: Yakov Shafranovich >> Cc: Ed Overflow ; saag >> Subject: Re: [saag] Best way to store digital certificates and/or > signatures in >> DNS >> >> Have you considered formatting the signature as a certificate and > submitting it >> to a CT log? That gives you an audit capability. >> >> BTW, I noticed that the draft says SHOULD for HTTPS, which is a much > bigger >> hole than this. >> >> On Tue, Feb 6, 2018 at 11:53 AM, Yakov Shafranovich >> wrote: >> > (This is related to this draft: >> > https://tools.ietf.org/html/draft-foudil-securitytxt-02) >> > >> > The proposed "security.txt" file has a matching optional >> > "security.txt.sig" file. One of the common issues we have received as >> > a feedback from potential users is a need to safeguard against the >> > possibility of an attacker compromising the webspace of a given >> > domain, and putting their own "security.txt" and "security.txt.sig" >> > files there. This will result in an attacker now receiving reports >> > about potential security issues in the compromised target. >> > >> > One of the proposed ways to try to fix this issue is to use DNS as > follows: >> > - to store the digital certificate that was used to generate the >> > signature file >> > - OR to store the signature itself in DNS >> > - OR to store the entire "security.txt" file in a DNS record instead >> > of being accessible via the web >> > >> > The logic behind this proposed solution is that web space tends to get >> > compromised more often and easier than DNS for any given domain. >> > >> > What I am wondering if there are any currently best accepted practices >> > to accomplish these goals in DNS with minimum disruption to the >> > Internet architecture as whole. Possibilities I was thinking of is >> > using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT >> > records like DKIM and SPF. >> > >> > Any recommendations, suggestions or comments are welcome. >> > >> > Thank you, >> > Yakov >> > >> > _______________________________________________ >> > saag mailing list >> > saag@ietf.org >> > https://www.ietf.org/mailman/listinfo/saag >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag From nobody Fri Feb 9 05:38:43 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE65126579 for ; Fri, 9 Feb 2018 05:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 3c9qfV4a8o_g for ; Fri, 9 Feb 2018 05:38:39 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 A2D89120726 for ; Fri, 9 Feb 2018 05:38:38 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 50B8E280172; Fri, 9 Feb 2018 14:38:36 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 4A1B3280B9B; Fri, 9 Feb 2018 14:38:36 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 435B2280172; Fri, 9 Feb 2018 14:38:36 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 3FFA4642BE40; Fri, 9 Feb 2018 14:38:36 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 367BD401CC; Fri, 9 Feb 2018 14:38:36 +0100 (CET) Date: Fri, 9 Feb 2018 14:38:36 +0100 From: Stephane Bortzmeyer To: Yakov Shafranovich Cc: Stephen Farrell , Randy Bush , Security Area Advisory Group Message-ID: <20180209133836.dxsrkuhhazju5mjr@nic.fr> References: <9BEEC091-F810-4534-8E54-8491AF8375FC@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.9.133016 Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 13:38:42 -0000 On Wed, Feb 07, 2018 at 10:25:52PM -0500, Yakov Shafranovich wrote a message of 28 lines which said: > A member of our project put together one such service here as a prototype: > https://registry.securitytext.org/ I tried to add google.com (which, according to the whois server, is not yet scanned) but I always get a "Too Many Attempts" % whois -h ipv4.whois.securitytext.org securityheaders.io % SECURITY TXT REGISTRY server at ipv4.whois.securitytext.org % for more information on SECURITY TXT REGISTRY, visit https://whois.securitytext.org/ % This query returned 1 object % "security.txt" on securityheaders.io: Domain: https://registry.securitytext.org/securityheaders.io Archive: https://registry.securitytext.org/domain/f1a2a1b0-fc6b-11e7-a7c9-bfab60ef78d3 Archive (API): https://registry.securitytext.org/api/v1/domain/f1a2a1b0-fc6b-11e7-a7c9-bfab60ef78d3 Contents: https://registry.securitytext.org/document/db301850-fc6d-11e7-ae5f-8d05bb40e31a Contents (API): https://registry.securitytext.org/api/v1/document/db301850-fc6d-11e7-ae5f-8d05bb40e31a Hash (SHA512): 9ed54eefbfefe0bf75f196e05d777fb083d12ff1e247f92168a57b423f1767ed46cc2911a9edb20d48ee75de57049437875... Created (UTC): 2018-01-18 16:37:21 Modified (UTC): (not implemented) Polled (UTC): 2018-01-18 16:37:21 ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> Contact: security@securityheaders.io -> -> Contact: https://twitter.com/securityheaders -> -> Encryption: https://scotthelme.co.uk/contact/ -> -> -> ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> % whois -h ipv4.whois.securitytext.org google.com % SECURITY TXT REGISTRY server at ipv4.whois.securitytext.org % for more information on SECURITY TXT REGISTRY, visit https://whois.securitytext.org/ % This query returned 0 objects % From nobody Fri Feb 9 07:26:51 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECF71200F1 for ; Fri, 9 Feb 2018 07:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 CqeRWP385hl1 for ; Fri, 9 Feb 2018 07:26:46 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.11]) (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 84086124205 for ; Fri, 9 Feb 2018 07:26:46 -0800 (PST) Received: from [216.82.251.38] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-11.bemta-12.messagelabs.com id 7C/A1-03103-5BDBD7A5; Fri, 09 Feb 2018 15:26:45 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGe2em01EZMxSQI8GFiolphIBLUmO MJCYGHtzxBTQ66EirbSGdirigNRISNK6pW5VFg1EJoJBUZBMlVlIUVIpNRUFxA4rGAHGPxpne 4vL2nfv/5/xnJvcypHqQjmKEXKtgMfNGDT2e8k13Vsc5m/LSEjzdjO7Gz9tI533wC+nsRwsJX f2TNjqJSi7+8ZxIrnP0qJLLyr4RyW+H7lIrqTSlwZyRlbtRqe9pPanK7kjN/dnlIWyoYflBNJ 6huI8EnPg8qpQLNWcnwOt+R+HChcDrPyAp4xiaSwBvUyshczgXBxfbX6pkJrkdUFVbSckcxqW C19VNYc9a6HOeoTEvhQHb00AvxcVC++UyUmaWWwelxadoHFZFgM05GjCN41bBow5XIABxk+BL WwWBwyKh+01JgIELh77H92nMETD4+pcS+9dB0WhL8FwDzyq/IsxToLPkEJLDgPOq4NLAXRUW4 sF5/EPQtAxGfG4lNhUS8L78ipTGSIUW/J552LMN2p29JOZ0uFfYEBzaT8CpC77gdtHw6lwjgQ U7DcO1RwIdam4z2MvH1tsN9uqz9DGkdfzzdQ6ph+RKEDT3O5SOwH8KBffZNxQ2aeFkpT/I06D 2w3kS80I48/0OjTkG7If6VJjnw5BrGJUiphzNEgVLjmCJm6eLz7AYMvVWE28wxiUmzok3CaLI ZwpGPkOM35RlqkHShdunUKCbaKQ5vQVNZghNBHvNkZemnpiRtXmnnhf1GyzbjYLYgqIZRgNsa 6OkhVqETCF3i8Eo3doxGZgQTTjbKcusmM2bREMmltrQXKbrdH8ByfgGhgpINWXOMgtRkaxPtn KyVb/d/GfQ2AvoRFOiwlikUCjUIdmCxWSw/q/7USSDNGFskTwlxGC2/snzS6sQ0io9SYFVrPx fKcqGbF2f3L1Fa1drQ9+v+F7Skx6RtMSzv2JxletYfuO56yOj37buXZGS7Rs8OrM5p/HFj/Mz rrafHol9OHVpW03KAm9eedVFV2iLe5FRmxJju1YYU7Arf1fk+jXDxtS66K0VV6vzPfUTatjnx ftW1t1aTy3q/bTnrXv34XfqhNlfB0OU1o4cDSXq+UQtaRH53wDokTb8AwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-9.tower-163.messagelabs.com!1518190004!155770212!1 X-Originating-IP: [216.32.181.177] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 77164 invoked from network); 9 Feb 2018 15:26:45 -0000 Received: from mail-by2nam01lp0177.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.177) by server-9.tower-163.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 9 Feb 2018 15:26:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YeegyF+8sK+S1QrTB3mr9LqSktfaXHGw365qF1p2Qf0=; b=LQMGn+10PN29p7+ABdyBUs0stQbtEitgaMixpD/r7nJdGHo6lT2HDHGgFdBfrRWnDnIKqmaVSLvR5wgV6V3RDqkNsAPmHo1N7RV0xYcx4Pf6UBjzvyn1VjHk3zUd0TfHmGLUPnuCQ5CbIhIObwrXO0c5oClwbuO351aSp91mvas= Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1840.namprd14.prod.outlook.com (10.171.148.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 9 Feb 2018 15:26:42 +0000 Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([10.173.232.139]) by MWHPR14MB1376.namprd14.prod.outlook.com ([10.173.232.139]) with mapi id 15.20.0485.009; Fri, 9 Feb 2018 15:26:42 +0000 From: Tim Hollebeek To: Martin Thomson CC: Yakov Shafranovich , Ed Overflow , saag Thread-Topic: [saag] Best way to store digital certificates and/or signatures in DNS Thread-Index: AQHTnuUFEnAVgGHXBkWYnq7Ag4jn/6OWjcmAgALAuXCAAgVVAIAA4d9Q Date: Fri, 9 Feb 2018 15:26:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR14MB1840; 6:x253aDh3nqk3JJwkmjsqkZYqwXvg87CRj8+wX3LTwOGZWImj6n/XHVyetSEZY0G7fEiDO+avjFsksWjynXs4qIjQya35NYaxoDxXyINv4hr2/CB5hzz+H8KkoNHcbsz9uqYschVhE0Md5NnwElccop5NWPzzmP5hEdxGw3CvV44Eo5EiFTzXxnrQgf/oFji0ydlABn+LQNMJLVUvtu992Wc4FTN3jeQFAF9H+3vWX5uG+FQhBw51NzeGWAPV6tiuB2YypTQMQXfrY9qy4PZsi8ZNDTud/LapmWEI8xCA1wfI8U/xJa2CkBIACLPpn1hq99dfUNsapg0UUUum0efxrg9CSKxTWLY13JK2/nN4SLXplVaZfAnZxfzSTD7bPpYf; 5:FNo/Y7cMIp4Uwlz1apsP9WAwU0uYlfk+lxctoDc8mULU2r+anOmywyJlsldA6HtyEDjR6wISzZ5c1H4cjpy/eceR8jXGrTBxzEPBNdsnD+R3DLnw0MQkD9W5QaRoz6HjNef7z6OviR5McAp3WjtvNo8ojT/awD0MPxPcMq5e4Jk=; 24:W/YJtu86wcPILhRAMGCiQ7AuMlo2/WooTxqtDkdE3JLUljEz7Jqi17TlfzWsYTjoIGLYE7YfH4ut4fgGBl9RXW9tKYxdaQVznlh6pNIbxUE=; 7:m4nlRZzq7aeOVBRfaLH+RwtaZqArlpnaOlyfoEmh730lHaIlPuZfEaN0L5jmRJd9dcaDFI6k1xxVzRe/2HOfo4nI6K/w+4Sub5DGiErENMdeRahqiq0AAZyZdiP1UmG927vJ/NCcgTzIErIn79nOQB5FFwkLk1Xjgi/MmrkmrBz5VJoKnbLcLOdsZlUqPD9IhGArhKk9sNsWJLKhFhDrc5gl+Tg5qpdo6Zlhy4LpBIBqU/uypoIlRkOtIu9Hmz9o x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3fad3986-002f-40b3-ce76-08d56fd18592 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7026125)(7024125)(7027125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1840; x-ms-traffictypediagnostic: MWHPR14MB1840: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(3002001)(10201501046)(93006095)(93001095)(6041288)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:MWHPR14MB1840; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1840; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7966004)(396003)(346002)(366004)(376002)(39860400002)(39380400002)(13464003)(189003)(199004)(5660300001)(74316002)(7736002)(305945005)(66066001)(186003)(55016002)(26005)(77096007)(6306002)(9686003)(68736007)(102836004)(316002)(53936002)(33656002)(3280700002)(4326008)(6916009)(25786009)(39060400002)(76176011)(2950100002)(59450400001)(6506007)(53546011)(6436002)(229853002)(3846002)(6116002)(508600001)(105586002)(81156014)(81166006)(93886005)(966005)(8936002)(97736004)(2900100001)(2906002)(14454004)(99936001)(8676002)(106356001)(7696005)(3660700001)(6246003)(86362001)(99286004)(54906003)(43043002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1840; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YmLh5LR9pQn7gHaR53I8Vv2fW8qM+Ygx4r4oaRH+H52A9bsMgrdhaTGH3YTmNmOUB7q+m+YjbOIUe2g1bGtjLw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_06EF_01D3A17F.AF703000" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3fad3986-002f-40b3-ce76-08d56fd18592 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 15:26:42.0444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1840 Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 15:26:50 -0000 ------=_NextPart_000_06EF_01D3A17F.AF703000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit CT logs are for auditing publicly trusted certificates issued by certificate authorities. Do not abuse them. Do not play games with EKUs to encapsulate random data into certificates. If we want *-transparency logs, perhaps based on the same software, then discuss that. But don't use the existing CT logs for anything other than their stated purpose. -Tim > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Thursday, February 8, 2018 6:54 PM > To: Tim Hollebeek > Cc: Yakov Shafranovich ; Ed Overflow > ; saag > Subject: Re: [saag] Best way to store digital certificates and/or signatures > in > DNS > > I thought that this would be a certificate. Maybe one with a new KU bit. > > On Thu, Feb 8, 2018 at 6:03 AM, Tim Hollebeek > wrote: > > Please do not abuse CT logs for non-certificate purposes. > > > > Doing so is probably the fastest way to convince CT log operators to > > be more restrictive about who they accept certificates from. We don't > > want that. > > > > -Tim > > > >> -----Original Message----- > >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Martin Thomson > >> Sent: Monday, February 5, 2018 6:00 PM > >> To: Yakov Shafranovich > >> Cc: Ed Overflow ; saag > >> Subject: Re: [saag] Best way to store digital certificates and/or > > signatures in > >> DNS > >> > >> Have you considered formatting the signature as a certificate and > > submitting it > >> to a CT log? That gives you an audit capability. > >> > >> BTW, I noticed that the draft says SHOULD for HTTPS, which is a much > > bigger > >> hole than this. > >> > >> On Tue, Feb 6, 2018 at 11:53 AM, Yakov Shafranovich > >> wrote: > >> > (This is related to this draft: > >> > https://tools.ietf.org/html/draft-foudil-securitytxt-02) > >> > > >> > The proposed "security.txt" file has a matching optional > >> > "security.txt.sig" file. One of the common issues we have received > >> > as a feedback from potential users is a need to safeguard against > >> > the possibility of an attacker compromising the webspace of a given > >> > domain, and putting their own "security.txt" and "security.txt.sig" > >> > files there. This will result in an attacker now receiving reports > >> > about potential security issues in the compromised target. > >> > > >> > One of the proposed ways to try to fix this issue is to use DNS as > > follows: > >> > - to store the digital certificate that was used to generate the > >> > signature file > >> > - OR to store the signature itself in DNS > >> > - OR to store the entire "security.txt" file in a DNS record > >> > instead of being accessible via the web > >> > > >> > The logic behind this proposed solution is that web space tends to > >> > get compromised more often and easier than DNS for any given domain. > >> > > >> > What I am wondering if there are any currently best accepted > >> > practices to accomplish these goals in DNS with minimum disruption > >> > to the Internet architecture as whole. Possibilities I was thinking > >> > of is using DANE and OPENPGPKEY records; CERT records, or perhaps > >> > even TXT records like DKIM and SPF. > >> > > >> > Any recommendations, suggestions or comments are welcome. > >> > > >> > Thank you, > >> > Yakov > >> > > >> > _______________________________________________ > >> > saag mailing list > >> > saag@ietf.org > >> > https://www.ietf.org/mailman/listinfo/saag > >> > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag ------=_NextPart_000_06EF_01D3A17F.AF703000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMjA5MTUyNjMwWjAvBgkqhkiG9w0BCQQxIgQgy9ZxLZ0ZIGHiLagNoHyVAD8kpWbl sOeYznqCUpRd2rAwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAFxu+bWg14a98/zGHysx6nsp03LftdqAL7GH+LTlRMKFpoEmY2kHY/JCTeGl2PwsxeEySoff lyT0zUK0pJ7E1Tsvxw+Z37hLeqeeKHPhW7vRxhHnCJ8Ljd16meWdHJ6uKOA1ilco9P780DoJsvHa envPH4BL0rOlYfeNattXoN7PvfuSSfrixgxA//Va5SlzkTZn7cpKPHUif+IgUkPArB/0DIUuqrt3 +Gu1ddnnu6WcdCKBiCSFgl+lwsv6/IpTedYiDg8V6ZmFVMoJNekTyZuHlqKvUUhD1NQXyhiDxxqw QwjvGBqXCbEAe9LKpOIOTqWVuF36fHrIEQHoc/78HzIAAAAAAAA= ------=_NextPart_000_06EF_01D3A17F.AF703000-- From nobody Fri Feb 9 08:19:50 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7552A1250B8 for ; Fri, 9 Feb 2018 08:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 v5RAlHuvZcPX for ; Fri, 9 Feb 2018 08:19:46 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 5A0801200FC for ; Fri, 9 Feb 2018 08:19:46 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id q9so8227321oti.0 for ; Fri, 09 Feb 2018 08:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rd8NGwqZNZjq1po0GUaEwR2Gj5sex73K2FWMO7TeMl8=; b=iYEEU3EErTjRmRqKkRW7+o9osr/e5ay6b8W9n3ocfcfG6X4V0kVk+IOTNZEljcdKZz 4W++cyTIaToVP5H21r9FkP1m1nJsTs0+U9n6HMMgdgil4rWAIRj2vGeneQLuCXOs7nKe 0Q0rK16qHZWwpIv4mPNNPNYw8nLATZhooqbLcr1tjFirkZcH96sBXNpy4rvL5Gw91Yp+ KUQHrqQjtRKtoH3RR4pZx02gUPvsMGNHk8fIfXjRzue1D1iFqs9SkU+33qfUbheFuY5e K9AHj8bJhBEfcIw4HW+cA4QMyr4F8vl81HlnWOncIaH/6d0No0mc2OBSjp04qw7ZEZtF 2kPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rd8NGwqZNZjq1po0GUaEwR2Gj5sex73K2FWMO7TeMl8=; b=r+6F50QQYVwlfprCJKCmth6KUJeV0WNg6F3w017GEus5MM1TJFbS+cUONxOCAKGBD+ D00+QVuZ9JOr7/ByxZ2PgNz+bHpbgYU+lqAwFXVSjPA35vpqUEO/HHUpSj2UnGyC9/M8 ZAd81+f8hM8MtpjUxFBxEjG3R+ZoJCu91px1mrJlvB023Q8yJyL6dcq3dKoMt9VAVZgs B2vt7sG5E0BnmhmRbfSMQXSqzL8Ye+NuQo/Ae6LsivfsV7h9jlFYv7Qw5dGptGXic4jT bFPZihTbCsymWwSXSOdEb/57WO1E9S1tB3lP/vWHazYsEbM7b+/Y0A5dgg7MyTPJkemn xsaA== X-Gm-Message-State: APf1xPBEjtZaO9cNmsyUqDKq/Y9kK6DiPN4movKy/wBl/YLH4TQ1jJcQ rcLuAHtwAjVTzgr8hEGNurKpCchsa7vg1xMU0aXU5e5k X-Google-Smtp-Source: AH8x2269BHWOG3Mz6zxVnq8Eh6YiGwG5zkEuV3Jk7TSMIYBujWPAUDU/JdlVtQzx/AHDimoAcpX0SKdoqFL4a+ycSJ8= X-Received: by 10.157.2.167 with SMTP id 36mr2471955otl.23.1518193185451; Fri, 09 Feb 2018 08:19:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.5 with HTTP; Fri, 9 Feb 2018 08:19:45 -0800 (PST) Received: by 10.157.23.5 with HTTP; Fri, 9 Feb 2018 08:19:45 -0800 (PST) From: Yakov Shafranovich Date: Fri, 9 Feb 2018 11:19:45 -0500 Message-ID: To: Security Area Advisory Group Content-Type: multipart/alternative; boundary="94eb2c09a3b68505660564c9e54c" Archived-At: Subject: [saag] Version -03 of draft-foudil-securitytxt posted X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 16:19:48 -0000 --94eb2c09a3b68505660564c9e54c Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message ---------- From: Date: Feb 9, 2018 11:11 AM Subject: New Version Notification for draft-foudil-securitytxt-03.txt To: "Edwin Foudil" , "Yakov Shafranovich" < yakov+ietf@nightwatchcybersecurity.com> Cc: A new version of I-D, draft-foudil-securitytxt-03.txt has been successfully submitted by Edwin Foudil and posted to the IETF repository. Name: draft-foudil-securitytxt Revision: 03 Title: A Method for Web Security Policies Document date: 2018-02-09 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-foudil- securitytxt-03.txt Status: https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ Htmlized: https://tools.ietf.org/html/draft-foudil-securitytxt-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-foudil- securitytxt-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt- 03 Abstract: When security risks in web services are discovered by independent security researchers who understand the severity of the risk, they often lack the channels to disclose them properly. As a result, security issues may be left unreported. security.txt defines a standard to help organizations describe the process for security researchers to disclose security vulnerabilities securely. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --94eb2c09a3b68505660564c9e54c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---------- Forwarded mes= sage ----------
From: <i= nternet-drafts@ietf.org>
Date: Feb 9, 2018 11:11 AM
Subject: N= ew Version Notification for draft-foudil-securitytxt-03.txt
To: "Ed= win Foudil" <contact@edov= erflow.com>, "Yakov Shafranovich" <yakov+ietf@nightwatchcybersecurity.= com>
Cc:

A new version of I-D, draft-foudil-securitytxt-03.txt
has been successfully submitted by Edwin Foudil and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-foudil-securitytxt
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A Method for Web Security Policies=
Document date:=C2=A0 2018-02-09
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-foudil-s= ecuritytxt-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-foudil-securitytxt/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-foudil-securitytxt-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt-0= 3
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-foudil-securitytxt-= 03

Abstract:
=C2=A0 =C2=A0When security risks in web services are discovered by independ= ent
=C2=A0 =C2=A0security researchers who understand the severity of the risk, = they
=C2=A0 =C2=A0often lack the channels to disclose them properly.=C2=A0 As a = result,
=C2=A0 =C2=A0security issues may be left unreported. security.txt defines a=
=C2=A0 =C2=A0standard to help organizations describe the process for securi= ty
=C2=A0 =C2=A0researchers to disclose security vulnerabilities securely.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c09a3b68505660564c9e54c-- From nobody Fri Feb 9 11:12:07 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59E412D80F for ; Fri, 9 Feb 2018 11:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Orcj-Bhkuzaz for ; Fri, 9 Feb 2018 11:12:01 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 3ACCF126DFF for ; Fri, 9 Feb 2018 11:12:01 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id h129so11922561ita.2 for ; Fri, 09 Feb 2018 11:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=aHzMYeLTQZgFeUfwrjSqCfEQSMXCVC59lJgZ6/9lN7c=; b=cGGTWSt4Mhf1b3tWZgVDrx4F0G/sS1MepwxjyBDD3tpVDVxrEWqiL21kLO6sTGVS5u /Otjfn9dlpmlmwKEUIwlNXJ8DX5ZCfSZuTa0tY2xhZD551W4hOQniECTrI9oK8fgryyZ ZV40WN88n+xeqgpugu2uHKUmp/PT6z94pzTKZIUGVAbRDWMlRDP5tAkw9sRetkXsJpsw Jheuo2NUgeYQd2LuJq6VyMtmtl4qNkT+PFGYiS1BkXB1FSyJGYYkyP5hkjm8XDzj+uPO fxhziiM7FTqXAzK1fXun65M0MUvU6xvzkIhuIgWibusHRFAzxnNJXAsrwJxprYqqh4vr F6rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=aHzMYeLTQZgFeUfwrjSqCfEQSMXCVC59lJgZ6/9lN7c=; b=tXyxhL37Sycog9ChxCWDVQMOtWuZthJz2EdlQxoiJCP6+JnwjX7ae2bh3LA740Ca2h vmgTaVc23hLWUnM8nuw0jkiaIaPsoVNi7sMNy9Kj4VTp6Yrogs1AfwnTBfgwsbirst2a OZh/XR3BMBQlKGXKNo9x+SmFjDEnBx+OA6J7UhSStCsuxH3AjvdcQmIc4yZsKSuW1jHJ SdXSt26n7QxBfuRmlaFWmZs1ACFqqrCL0hJKhHfDu5Pum5GBY3RqRRngpO6+LbT14wwS YM+EAFLJ9L9hoLTTxsF0Vov5Z+7HAlT+lJAZ2a69ari0WASUUZVsjsqf0C0z/3LzCs4Q vYNg== X-Gm-Message-State: APf1xPDtxVwX1ozD7f83J0uMvQjcPER1dEqrjfoMcUGl3Fgj4zjh5bWj 2Q1vHJlZwsZozjpxk3ohNRtaAg== X-Google-Smtp-Source: AH8x226gI8VpYxw89/Go4SH4DFGehYI8Xb57w48Inc8+yx/4cBpvgHPtI1v4ZlLeyhxMMzzE2DbLLQ== X-Received: by 10.36.118.21 with SMTP id z21mr4715012itb.116.1518203520088; Fri, 09 Feb 2018 11:12:00 -0800 (PST) Received: from aspen.local (63-140-68-28-radius.dynamic.acsalaska.net. [63.140.68.28]) by smtp.gmail.com with ESMTPSA id d3sm3813735ite.36.2018.02.09.11.11.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 11:11:58 -0800 (PST) To: saag@ietf.org References: From: Melinda Shore Message-ID: <96328d21-3590-374c-8a21-b2b807373f2e@gmail.com> Date: Fri, 9 Feb 2018 10:11:55 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Dy5upLWtPYWNXWsw8q0LNnHmmFB8S7Em0" Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 19:12:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Dy5upLWtPYWNXWsw8q0LNnHmmFB8S7Em0 Content-Type: multipart/mixed; boundary="0yzQCbAGXdQ68ak6Zw18gstfZgzSGD5Xg"; protected-headers="v1" From: Melinda Shore To: saag@ietf.org Message-ID: <96328d21-3590-374c-8a21-b2b807373f2e@gmail.com> Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS References: In-Reply-To: --0yzQCbAGXdQ68ak6Zw18gstfZgzSGD5Xg Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/9/18 6:26 AM, Tim Hollebeek wrote: > Do not abuse them. Do not play games with EKUs to encapsulate random > data into certificates. Well, a bit late for that. More to the point there's currently no policy that prevents folks from doing just that and I think it would be difficult to construct one that couldn't be trivially gamed. This is one of those cases where providing a usable alternative can stop this and there isn't enough entrenched existing practice to break much if a good alternative is provided in a timely way. I've mentioned Google's "General Transparency" project before and I'll mention it again. I'm not sure it's quite the right approach here but I don't think it's terribly wrong. Melinda --0yzQCbAGXdQ68ak6Zw18gstfZgzSGD5Xg-- --Dy5upLWtPYWNXWsw8q0LNnHmmFB8S7Em0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJMBAEBCgA2FiEET2gtkyoXlvgg8jTA37iRcpp2248FAlp98nwYHG1lbGluZGEu c2hvcmVAZ21haWwuY29tAAoJEN+4kXKadtuPlUoP/jBSts5iHKHtmqDRWexbMHF5 P+4uDlk1te26afmsL8w8Sr4xlXpVscvS8zMlVcLLO6eNi0ZO9HdaOk2sQURffOS9 xyD6vYwTuCM2e2/dcMKNx60OD/o4lffCWWuDBKJjZU8YAkcvYMI7guUm6g7KyY35 1I7VFuiWxYyNUnof/tO/mBCAFPeaFbOq/fO0z7+SxJasJ7+mQLyGncJhtWpTQTog ku9qZ/pvN4pIr5Hfs8EI4QHBbRDNFf0dlGx61UokVk+/U1BU2uwV4XXZgQFsUlro NP752KOvtNyvtBY78PRE1fVlpF+DG56YOr+91NUNZYoz44/xYZ3pwaFWzQ53fVkN tF3jF6saigBG2rFjkzakzDuVWD3FE/2Knl8BXcCBeArY1A2P88VNZIo8KIxXv1iu 0G4DvBA9hZTh642ksPnmJoiKeiOLBR0XOOQ9+/iTQ5vijSiUl3LP/R2w4b9J6DCH Vld1N+rZAcJteyXjFUEOJPR+U1s9yt1X2p+egIRW+jiZCVuJEOXIuR95/VNmi+od p/TCGHxIDhvyb7mqA+5XxtwJ3cWI0huRSrAy5dhU9oHfIy/LAQ+ix2XEvRhPKRYM lnSlBZ8GL0aD99vP/k1EMj0fIV1HcC15mBDUfYcqgIW2P4m3dLUKlHXi4foA+Ote AxP860ZNZa3BU3lhDD5f =I1U6 -----END PGP SIGNATURE----- --Dy5upLWtPYWNXWsw8q0LNnHmmFB8S7Em0-- From nobody Fri Feb 9 13:15:46 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6941270A3 for ; Fri, 9 Feb 2018 13:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 hG2nt9IP2Cjn for ; Fri, 9 Feb 2018 13:15:43 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D95D1242F7 for ; Fri, 9 Feb 2018 13:15:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EC791300A0C for ; Fri, 9 Feb 2018 16:15:40 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4gso7Qq0Hvky for ; Fri, 9 Feb 2018 16:15:39 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7F8C730044B; Fri, 9 Feb 2018 16:15:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Fri, 9 Feb 2018 16:15:40 -0500 Cc: IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <15B1BD0A-0F09-431A-832B-7F1AD26F6942@vigilsec.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> To: Yakov Shafranovich X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 21:15:45 -0000 Sorting the certificate in the DNS seems like a reasonable step, but it = seems like a hash of the security.txt would be enough if the zone is = DNSSEC signed. Russ P.S. I would rather see the file called security.txt.p7s and the = detached CMS signature conventions followed. > On Feb 6, 2018, at 4:52 PM, Yakov Shafranovich = wrote: >=20 > Hi Randy, >=20 > That is kind of what prompted my earlier question to the list > regarding DNS here: > https://www.ietf.org/mail-archive/web/saag/current/msg08098.html >=20 > For the signature, one proposal bouncing around so far has been to > have the signature inline, the other proposal which is in the draft is > to have a second signature file placed next to the file. As you have > highlighted, in both cases there is no definition of what type of > signature it actually is. I don't have a problem standardizing on PGP > signatures but that would kind of lock the proposal to PGP only and I > was hoping to something more extensible. >=20 > The obvious bigger problem is that no matter where the signature is > placed (inline or separately), how do we make sure that the signature > is legit? If an attacker can compromise the webspace, then presumingly > they can compromise the signature as well. One proposed solution has > been to ties the authentication of the signature to the domain where > the "security.txt" file is actually placed, and then rely on the fact > that it is harder to compromise DNS vs. the web. Empirical evidence > suggests that may be true but I am not entirely sure. Another > possibility is to tie it to the domain via a CA-issued certificate, > thus relying on the CA verification. However, with LetsEncrypt and > ACME. the webspace (i.e. "well-known" directory) is used for > verification as well, so that puts us back at square one. >=20 > Regarding the encryption header, that is the key meant to be used for > encrypting communication between the reporter and the receiving > entity: >=20 > 2.4. Encryption: >=20 > This directive allows you to add your key for encrypted > communication. You MUST NOT directly add your key. The value MUST > be a link to a page which contains your key. Keys SHOULD be loaded > over HTTPS. >=20 > Thanks >=20 > On Tue, Feb 6, 2018 at 9:46 AM, Randy Bush wrote: >> for fun, and because it seemed trivial, i hacked up a security.txt = for >> https://rg.net/.well-known/security.txt >>=20 >> the document has issues (he said trying to learn californian). e.g. >>=20 >> 2.5. Signature: >>=20 >> In order to ensure the authenticty of the security.txt file one >> SHOULD use the "Signature:" directive, which allows you to link to = an >> external signature. External signature files should be named >> "security.txt.sig" and also be placed under the /.well-known/ path. >> External signature files SHOULD be loaded over HTTPS. >>=20 >> Here is an example of an external signature file. >>=20 >> Signature: https://example.com/.well-known/security.txt.sig >>=20 >> that is not "an example of an external signature file" at all. it is = an >> example of a Signature: line in a security.txt file. in fact, there = is >> no definition of a signature file or what it contains other than this >> hint. >>=20 >> To ensure the authenticity of the security.txt file, organizations >> SHOULD sign the file and include the signature using the = "Signature:" >> directive. >>=20 >> so i guessed and `gpg --clear-signed` the security.txt file with the = pgp >> key referenced by the "Encryption:" line, producing security.txt.sig >> (although the convention would name it .asc). but i have no belief = that >> this ensures the authenticity of anything. >>=20 >> randy >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Feb 9 13:47:23 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA65127369 for ; Fri, 9 Feb 2018 13:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 fQ3-ZKziQSb6 for ; Fri, 9 Feb 2018 13:47:19 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334471273B1 for ; Fri, 9 Feb 2018 13:47:19 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 38A658182D01; Fri, 9 Feb 2018 21:47:18 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-69.brq.redhat.com [10.40.204.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id 609A0FA2BA; Fri, 9 Feb 2018 21:47:16 +0000 (UTC) To: Yakov Shafranovich Cc: saag References: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> From: Paul Wouters Message-ID: <4fda1ac8-4732-f41d-2aa1-201622629f5e@redhat.com> Date: Fri, 9 Feb 2018 16:47:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 09 Feb 2018 21:47:18 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Fri, 09 Feb 2018 21:47:18 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pwouters@redhat.com' RCPT:'' Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 21:47:21 -0000 On 02/07/2018 10:44 PM, Yakov Shafranovich wrote: > I am not that familiar with RDAP - are the RDAP servers run by TLD > registries and RIRs only? And how would this work for domain admins - > would they need support from their registrar to put the info in, which > would then feed into the TLD registry? RDAP is a WHOIS replacement. It can (soon MUST) be used by RIR's and Registrars. In this case I was thinking of Registrars. While that does not address the subdomains potentially going to a different security contact from the main domain, I personally don't see much value in random sysadmins in an organization throwing up random webservers with their security.txt. If those servers are compromised, it will include compromising security.txt but more likely the server will be forgotten, the security contact will have left the company, and the security.txt content is useless. A valuable security contact is a contact that is known to be a stable reference before any incident happens. Again, taking twitter as example, I'm much better of contacting the company's twitter account (which will be a visible and stable entity) then follow the information of security.txt found on a random (and insecure!) server. I also think the entity's home page's "contact" link would be a more reliable method of finding a proper contact. Sure, it is not an automated method. But automated contacts (like those in WHOIS/RDAP) also get so much spam these email addresses are often abandoned anyway. In short. The idea is cute but I see no practical value. I do see it as an additional danger of people trusting untrusted information. Paul From nobody Fri Feb 9 14:07:28 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927D3127241 for ; Fri, 9 Feb 2018 14:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 D0I1MM_PORSC for ; Fri, 9 Feb 2018 14:07:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49821270FC for ; Fri, 9 Feb 2018 14:07:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8693F20091 for ; Fri, 9 Feb 2018 17:14:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E7A0F8115F for ; Fri, 9 Feb 2018 17:07:22 -0500 (EST) From: Michael Richardson To: saag In-Reply-To: <4fda1ac8-4732-f41d-2aa1-201622629f5e@redhat.com> References: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> <4fda1ac8-4732-f41d-2aa1-201622629f5e@redhat.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 22:07:26 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > While that does not address the subdomains potentially going to a different security > contact from the main domain, I personally don't see much value in random sysadmins in > an organization throwing up random webservers with their security.txt. If those servers > are compromised, it will include compromising security.txt but more likely the server > will be forgotten, the security contact will have left the company, and the security.txt > content is useless. I don't think this is the use case for security.txt. > A valuable security contact is a contact that is known to be a stable reference before any > incident happens. Again, taking twitter as example, I'm much better of > contacting the company's > twitter account (which will be a visible and stable entity) then follow the information of > security.txt found on a random (and insecure!) server. That's true for some entities, but very much untrue for others. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlp+G5oACgkQgItw+93Q 3WVKWgf+MlxHETXCbnPcVakiil03qZoAUkOsm76TxfqJjyQ/nfsdK+YBh60pwnKK cpQibGCJ1uOG7MJn1IhcuvWD6Zn7foV/kmyElGsrmcILiRwuFFET+2ThTI5z0NjL wi+21U+vSDiuBLrMUWW+irmqmAlGr6rlhg9gAeP/KXJs4kmSf5hPR7/6eGt3osHe uplYrpgwcs2enYb0x3ZyQwOd8DFA41diFg6vrXXE2T2hqvr5ZMS3Lie3LuUksj0F 8kAkJV/LNOsZjsTKsAEo7jny6SwxbnO+BOWZFBIEIrl6pK2J0qctbAk+wlc3SJLd ODEt0QHnIogyNNhy578SjqFHaORL8Q== =eBD7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 9 20:55:29 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC7126C26 for ; Fri, 9 Feb 2018 20:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 YruBOfCGPrxz for ; Fri, 9 Feb 2018 20:55:27 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 1F8511241F8 for ; Fri, 9 Feb 2018 20:55:27 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ekNC8-0002EF-5V; Sat, 10 Feb 2018 04:55:24 +0000 Date: Sat, 10 Feb 2018 13:55:23 +0900 Message-ID: From: Randy Bush To: Russ Housley Cc: Yakov Shafranovich , IETF SAAG In-Reply-To: <15B1BD0A-0F09-431A-832B-7F1AD26F6942@vigilsec.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <15B1BD0A-0F09-431A-832B-7F1AD26F6942@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2018 04:55:28 -0000 > P.S. I would rather see the file called security.txt.p7s and the > detached CMS signature conventions followed. you seem to assume x.509 From nobody Tue Feb 13 09:25:05 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D8512D84C for ; Tue, 13 Feb 2018 09:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 C61yuLU76hDz for ; Tue, 13 Feb 2018 09:25:02 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2719012D7EA for ; Tue, 13 Feb 2018 09:25:02 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3679A81638F0 for ; Tue, 13 Feb 2018 17:25:01 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-69.brq.redhat.com [10.40.204.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id B135E946A9 for ; Tue, 13 Feb 2018 17:25:00 +0000 (UTC) To: saag References: <3f455de8-f7d2-dc25-746b-77b5e9a39700@redhat.com> <4fda1ac8-4732-f41d-2aa1-201622629f5e@redhat.com> <27530.1518214042@obiwan.sandelman.ca> From: Paul Wouters Message-ID: Date: Tue, 13 Feb 2018 12:24:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <27530.1518214042@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 13 Feb 2018 17:25:01 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 13 Feb 2018 17:25:01 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'pwouters@redhat.com' RCPT:'' Archived-At: Subject: Re: [saag] Best way to store digital certificates and/or signatures in DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 17:25:04 -0000 On 02/09/2018 05:07 PM, Michael Richardson wrote: > > Paul Wouters wrote: > > While that does not address the subdomains potentially going to a different security > > contact from the main domain, I personally don't see much value in random sysadmins in > > an organization throwing up random webservers with their security.txt. If those servers > > are compromised, it will include compromising security.txt but more likely the server > > will be forgotten, the security contact will have left the company, and the security.txt > > content is useless. > > I don't think this is the use case for security.txt The draft states: Security.txt defines a standard to help organizations define the process for security researchers to securely disclose security vulnerabilities. Note "securely". It does not actually do that. It insecurely presents contact information that has a higher change of having been modified by the attacker since the service is in need of a security researcher contacting them about a vulnerability. You would hope the security researcher would find a more secure avenue of contacting the owner of the web service in question. > > A valuable security contact is a contact that is known to be a stable reference before any > > incident happens. Again, taking twitter as example, I'm much better of > > contacting the company's > > twitter account (which will be a visible and stable entity) then follow the information of > > security.txt found on a random (and insecure!) server. > > That's true for some entities, but very much untrue for others. security that sometimes work, doesn't work. There is no reason to believe security.txt will be better maintained then the "contact" link on the website, or the abuse/security contact in WHOIS (or RDAP). And since it is guaranteed to be of an equal or weaker security level then every other contact method currently available. Like I said, it is a cute idea, but not a good idea. Paul From nobody Wed Feb 14 14:11:18 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B04A12426E for ; Wed, 14 Feb 2018 14:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 sEClkHWW4VLf for ; Wed, 14 Feb 2018 14:11:14 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DAD1201FA for ; Wed, 14 Feb 2018 14:11:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 81103300A03 for ; Wed, 14 Feb 2018 17:11:12 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yrnivjnw3LqG for ; Wed, 14 Feb 2018 17:11:11 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 936E1300435; Wed, 14 Feb 2018 17:11:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Wed, 14 Feb 2018 17:11:12 -0500 Cc: Yakov Shafranovich , IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <8A914AAC-E43F-4375-AC40-AA951B13DE56@vigilsec.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <15B1BD0A-0F09-431A-832B-7F1AD26F6942@vigilsec.com> To: Randy Bush X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:11:16 -0000 Randy: > P.S. I would rather see the file called security.txt.p7s and the >> detached CMS signature conventions followed. >=20 > you seem to assume x.509 One of the approaches that was offered is to put a certificate in the = DNS that can be used to validate the signature on the security.txt file, = regardless of where it is stored or how it is fetched. In that context, = yes, I am assuming X.509. I realize that other approaches have also been discussed, including = storing a hash of the security.txt file in the DNS. This seems like a = fine solution if the DNS zone is signed with DNSSEC. In this solution, = there is no need for a certificate of any sort. Russ= From nobody Wed Feb 14 14:30:07 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6940E12426E for ; Wed, 14 Feb 2018 14:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 3PdGR4XYHZvW for ; Wed, 14 Feb 2018 14:30:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E331201FA for ; Wed, 14 Feb 2018 14:30:04 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 321DA20090 for ; Wed, 14 Feb 2018 17:37:02 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2895380639 for ; Wed, 14 Feb 2018 17:30:03 -0500 (EST) From: Michael Richardson To: saag X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Wed, 14 Feb 2018 17:30:03 -0500 Message-ID: <15154.1518647403@obiwan.sandelman.ca> Archived-At: Subject: [saag] ALG or application-layer gateway references X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:30:06 -0000 RFC1928 (SOCKS) seems to be one for the first references I found in an RFC to application-layer gateways. (Good ol' Authenticated Firewall Traversal...) ALG otherwise has a wikipedia entry. I'm never happy citing Wikipedia if I can cite an RFC instead. Any suggestions? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Feb 14 14:43:48 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9B01201FA for ; Wed, 14 Feb 2018 14:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 wF3k4ZF6MMi3 for ; Wed, 14 Feb 2018 14:43:45 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 040D512426E for ; Wed, 14 Feb 2018 14:43:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1em5mB-0006KS-37; Wed, 14 Feb 2018 22:43:43 +0000 Date: Wed, 14 Feb 2018 14:43:42 -0800 Message-ID: From: Randy Bush To: Russ Housley Cc: Yakov Shafranovich , IETF SAAG In-Reply-To: <8A914AAC-E43F-4375-AC40-AA951B13DE56@vigilsec.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> <15B1BD0A-0F09-431A-832B-7F1AD26F6942@vigilsec.com> <8A914AAC-E43F-4375-AC40-AA951B13DE56@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:43:47 -0000 makes sense randy From nobody Wed Feb 14 16:38:26 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93520129C6C for ; Wed, 14 Feb 2018 16:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 v8tviyhfvWas for ; Wed, 14 Feb 2018 16:38:23 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C61126D74 for ; Wed, 14 Feb 2018 16:38:23 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 89FF51CAE41 for ; Wed, 14 Feb 2018 16:37:51 -0800 (PST) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by c8a.amsl.com (Postfix) with ESMTPSA id 67CB21CADF8 for ; Wed, 14 Feb 2018 16:37:51 -0800 (PST) Received: by mail-it0-f41.google.com with SMTP id 18so1984315itj.1 for ; Wed, 14 Feb 2018 16:38:23 -0800 (PST) X-Gm-Message-State: APf1xPDhhrzePMlQTx9lNe2z+LvFqTuRpF6UBn6JKSB40PbTzESvpcAO FaHOUxW1eoIkFyPBlY/rIkMNJOtr0Mrl1fmZbw4= X-Google-Smtp-Source: AH8x224RNPAfjLHNaYb7MOhCxaroTZprrglChJ5i6HelSwWGmTZYDFG2TyBvJqGapEEbdsNQ3K+99boKgPewCDG7uhs= X-Received: by 10.36.78.81 with SMTP id r78mr1180708ita.110.1518655102594; Wed, 14 Feb 2018 16:38:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.1.68 with HTTP; Wed, 14 Feb 2018 16:38:02 -0800 (PST) From: Glen Date: Wed, 14 Feb 2018 16:38:02 -0800 X-Gmail-Original-Message-ID: Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="001a11372c2ced3288056535719d" Archived-At: Subject: [saag] Possible missed messages on this list X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 00:38:24 -0000 --001a11372c2ced3288056535719d Content-Type: text/plain; charset="UTF-8" Possible missed messages on this list Dear list participants - An upgrade to the IETF's custom mail processing software today resulted in some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours. We invite you to check the mail archives for this list, at: https://mailarchive.ietf.org/arch/search/?email_list=saag to ensure that you have received all the relevant messages for this list today. We apologize for the inconvenience. Glen -- Glen Barney IT Director AMS (IETF Secretariat) --001a11372c2ced3288056535719d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Possible missed messages on this list

Dear list participants -
An upgrade to the IETF's custom mail processing software today resulted i= n some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours.

We invite you to check the mail archiv= es for this list, at:

https://mailarchive.ietf.org/arch/search/?email_l= ist=3Dsaag

to ensure that you have received all the relevant mes= sages for this list today.

We apologize for the inconvenience.
Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)



--001a11372c2ced3288056535719d-- From nobody Wed Feb 14 17:22:49 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907EB12AF6E for ; Wed, 14 Feb 2018 17:22:48 -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, 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 5gMaFot1L78t for ; Wed, 14 Feb 2018 17:22:46 -0800 (PST) Received: from mail-pl0-x244.google.com (mail-pl0-x244.google.com [IPv6:2607:f8b0:400e:c01::244]) (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 D243512D868 for ; Wed, 14 Feb 2018 17:22:46 -0800 (PST) Received: by mail-pl0-x244.google.com with SMTP id t4so9577589plo.0 for ; Wed, 14 Feb 2018 17:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=PKep54y0D/R4FW65mtPO14Wel0/BUqC0yQfBLxYZd58=; b=PeySpYQET+FTt7kyY+KsD87TKcZVsSWXEWS7cBpRvKOSxBqdCeyA4Dzr/3m85AlcFy PnwA5OY6fXW5aFeejm7mNd5JcXClAYtCCyw9gAkOMK1Dc1XxOuQLHAGo47wkQNdhBlRS CGmmFhohW30KsWk7Fmf4uzWXteOSsIF6Csj8cAVDJDFxaEGftRAP7r3ctIMtbg5Uec0X Y6elT1ctMgrzDlhIpVdR3a9AZ0P4lok6XVmM4z4qDmWx3xqaMpCrWEVBZ1ziuozVJgQR 6mpNTTeNvhu5IkuP+1OARQPHUPGdvnXfDf/cp3QOvSrweNa8YQhHLr02Nv0g0jZswtey Kl8Q== 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 :subject:message-id:date:cc:to; bh=PKep54y0D/R4FW65mtPO14Wel0/BUqC0yQfBLxYZd58=; b=CdBlEQg55vy6QE32YhpeAzngG25g0DXWQP+aNAQw24TrkEyGl8G4ihqHmaqlpjdUu3 5zwB9ZbXiXKZb0AM1XfnQe90phbGWD/n+YFtab5Y4FYSBWqHVihwBZkoZsR9eut1aI/g lsfAf44oWWpzzuJZu9iJS+KIDgTGtxKq2XmfeFb0vkLyT/WTjPEX4rSRbLT3QJawnZMl FDUgy0XkNGLRJA7/V7FvgpHhqizGQclepm+/BrWSxcAnAKjWOkPKb8gK3YhgcFCkLRk5 H4MarPFLRxxjGeQe/Y6UNl2VO4gVb18eHUymFMD3ulCgn2N6NCIA2k/Kq/zy7+QryUdA Fh1w== X-Gm-Message-State: APf1xPCW99zozYB33l0gSwm4R161cd3cWcmdUNtbMmX5su1eTd7z70nX wQdYFHMCS45lCdv4/yTQpH++hP+2 X-Google-Smtp-Source: AH8x226BMRUmT8S++CDji0gzbEneXgO0uArTAN9CmbNhYFvUZw/P7cREkGjYj/vi18Eei7Dv9w0bEA== X-Received: by 2002:a17:902:6f08:: with SMTP id w8-v6mr862980plk.155.1518657766326; Wed, 14 Feb 2018 17:22:46 -0800 (PST) Received: from prome-1n-dhcp2-160.eng.vmware.com ([208.91.1.34]) by smtp.gmail.com with ESMTPSA id s12sm21737328pfh.7.2018.02.14.17.22.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 17:22:45 -0800 (PST) From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <441D3CF8-E1E2-4E75-B9FD-C5E6286AB5FD@gmail.com> Date: Wed, 14 Feb 2018 17:22:44 -0800 Cc: saag@ietf.org To: mcr@sandelman.ca X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] ALG or application-layer gateway references X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 01:22:49 -0000 Michael Richardson wrote: > RFC1928 (SOCKS) seems to be one for the first references I found in an = RFC to application-layer gateways. (Good ol' Authenticated Firewall = Traversal...)=20 >=20 > ALG otherwise has a wikipedia entry.=20 >=20 > I'm never happy citing Wikipedia if I can cite an RFC instead. Any = suggestions? Earliest strong citation I find is RFC2663's section 2.9, = https://tools.ietf.org/html/rfc2663#section-2.9 -d From nobody Thu Feb 15 08:53:50 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EC712DA6B for ; Thu, 15 Feb 2018 08:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 VBXfXy_elKBZ for ; Thu, 15 Feb 2018 08:53:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EB912D969 for ; Thu, 15 Feb 2018 08:53:46 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 81B6920090; Thu, 15 Feb 2018 12:00:45 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 15CD480AE1; Thu, 15 Feb 2018 11:53:42 -0500 (EST) From: Michael Richardson To: Dan Wing cc: saag@ietf.org In-Reply-To: <441D3CF8-E1E2-4E75-B9FD-C5E6286AB5FD@gmail.com> References: <441D3CF8-E1E2-4E75-B9FD-C5E6286AB5FD@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] ALG or application-layer gateway references X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 16:53:49 -0000 --=-=-= Content-Type: text/plain Dan Wing wrote: >> RFC1928 (SOCKS) seems to be one for the first references I found in an >>RFC to application-layer gateways. (Good ol' Authenticated Firewall >>Traversal...) >> >> ALG otherwise has a wikipedia entry. >> >> I'm never happy citing Wikipedia if I can cite an RFC instead. Any suggestions? > Earliest strong citation I find is RFC2663's section 2.9, > https://tools.ietf.org/html/rfc2663#section-2.9 Thanks that one works well for me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqFuxUACgkQgItw+93Q 3WV3Ggf9HrIOmGEM7SEn+8qI7HQViw/EZ/adlS3aI24vEz71LIo1v7wGfPAqALSj CVOARt3RXWfB7nQh3sUeUMXeoH/Cbw7Qk1LniVk7ufOYlJHyIyGaxWg0IwZj5IO0 MJQbNrSvB7q8CnnO1R4tLH5yIKLULw/ykmcxq46p8PeNpOSwSsN/0GV9amDf9ghf dDKvyZib5SgCezYVBSpv9/k4bVToLNnzweqUhx+LWRw9/tY4w9sKc9q3cayUX5fc UaFcbLiJRL2Vyh+Ucx0dug+QIGfvvSFJ+K158y2yCxC5rF1etioHOGZuzKvrOaFZ +RccLuGr+wbY9bo7MMUTSdYtvO9FeA== =jAK8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 15 18:34:04 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9477C1270AC for ; Thu, 15 Feb 2018 18:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nightwatchcybersecurity-com.20150623.gappssmtp.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 V2YaqbtZRyqb for ; Thu, 15 Feb 2018 18:34:00 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 686F4126DEE for ; Thu, 15 Feb 2018 18:34:00 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id l10so1610654oth.1 for ; Thu, 15 Feb 2018 18:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=fOSjw0NxL8U98zc/A1y5zQeMxqkXEDSwLy2ScJNFUJ4=; b=OXp1SzlMvw1Lw7n5C3GRgstYJMdg/wWCbmw4XxlYZXf4H+184y3AP9BbWI1dxwb1ng Xkdl0TFZ8qEBRB5Cs0M2xb+eC898ALo5SwquJIKdGdIy50FX2jQqoyfr/uiPtkQbTWaN cdj86Cqn0StX8LgIpQvqmS7RygeiJuKip655lZqDfzElLDVwj9Bfr3hAhhCbpDx1v17/ PYLSkRYpVhwM4s8aJSNKF9OPMBtMRNVrZMZ6w585U7fsjhmgpw0i+mJT9iF/TsPW9h+G 9rHMdtoccJ2l0LaIToSLyNzgImffRjSIot6eFK7qmvaYJBGSW4UzES+ZDFx4Din2Sspu mQoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fOSjw0NxL8U98zc/A1y5zQeMxqkXEDSwLy2ScJNFUJ4=; b=GW++xmhLUCqChdpsRXyPQGMYq5/P2ANx9dU5Aj04dzkjWd0OgIv2vy1dEWVb7OgL/r 04zQxJe+OaF8TgDuDJ3dWtwLc8qdxjflUG7oi5ATmEDSHrS3XZz9e/rd9bmTWR8l+sOR mPypyh8rSh3Edpa1JcnqNOaYoAoBr/QwrnpeW3gIgUE8uE/h0LHYECZ/3udBpYOFD/y8 Vz1w4q0yC55aQpRRqoM8mBia7yiVcfSALOL3CR55RS+KSWDn1rrxH7Dnbk1as2mMZ24L 3cjGMx+wRORvsRDQNao88hwTZc8o6TqdYUKiclOw78sa3lQNA7kFoixON/Djf2ecKPN8 xeGQ== X-Gm-Message-State: APf1xPC92w+ntHqBvFf2kiyx/jmJuwE+Sn+I7KHiYMsbXI0qN+Vzy2ZZ wvCvnQ2hL+RDgIJghihuTbVJ1NGOJB+9JSdpgCRh1oMB/Fs= X-Google-Smtp-Source: AH8x224RdJb2VX9SaC3DO6IbtB3JdQTsCsBT7NOfDVsuLLdFSy+SmNjJ9lYd39CAksTOW5y3qzW7waFnWoB+ZCHD2Lk= X-Received: by 10.157.112.204 with SMTP id w12mr3639334otj.144.1518748439539; Thu, 15 Feb 2018 18:33:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.82.136 with HTTP; Thu, 15 Feb 2018 18:33:19 -0800 (PST) From: Yakov Shafranovich Date: Thu, 15 Feb 2018 21:33:19 -0500 Message-ID: To: Security Area Advisory Group Cc: Ed Overflow Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] DNS hash proposal for security.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 02:34:03 -0000 Hi, I specifically want to ask about the idea that Randy Bush mentioned - generating a hash of the security.txt file, and placing it in DNS as a simpler way to verifying the integrity of the file. This would also avoid a separate signature file, and mucking around with certs. As mentioned earlier by Stephane Bortzmeyer, the goal would be something lightweight. Another design goal would be to "good enough" security, as opposed to perfect security. As Stephane as noted in another message: https://www.ietf.org/mail-archive/web/saag/current/msg08126.html >> I suggest we do not try to find out whether DNS is secure than the Web >> or the opposite. Instead, we could rely on the fact that it is at >> least harder to compromise both DNS and the Web than the DNS alone or >> the Web alone. So, putting info in the Web and a way to check it >> elsewhere (in the DNS) seems reasonable. We don't want a >> military-grade solution, just something that it is not obvious for an >> attacker to compromise. The proposal would be as following: - After someone creates the security.txt file, they would calculate an SHA-256 hash, and then place it in DNS of the same domain or subdomain as the one serving the "security.txt" file - The hash would specifically be placed under "hash._securitytxt.example.com", as per RFC 2782, in a TXT record - The format of the hash would be the hex representation of SHA-256 - something like: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - Possible extensibility may be accomplished by using a format like: sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 I am aware of both RFC 6920 and 8315 but I think their encoding of the hash may make this too heavy to pull off for most admins. What I was thinking of is more like the following draft which never ended up being approved: https://tools.ietf.org/html/draft-thiemann-hash-urn-01 The level of effort involved here would be pretty much the same as putting in SPF records, and way less complex that DKIM which involves keys. Thank you From nobody Thu Feb 15 19:00:54 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3111243F3 for ; Thu, 15 Feb 2018 19:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3MVHCuy-WQE5 for ; Thu, 15 Feb 2018 19:00:50 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BD0126CD6 for ; Thu, 15 Feb 2018 19:00:50 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id DB1D67A3309 for ; Fri, 16 Feb 2018 03:00:48 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 15 Feb 2018 22:00:46 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: saag@ietf.org Message-Id: <85BBE78C-B14B-4CED-A3F1-1799856C7173@dukhovni.org> References: To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] DNS hash proposal for security.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 03:00:52 -0000 > On Feb 15, 2018, at 9:33 PM, Yakov Shafranovich = wrote: >=20 > I specifically want to ask about the idea that Randy Bush mentioned - > generating a hash of the security.txt file, and placing it in DNS as a > simpler way to verifying the integrity of the file. This would also > avoid a separate signature file, and mucking around with certs. If DNS is simple and secure enough to publish the hash, why not dispense with the hash, and just publish the data in the DNS? The SOA record = already has an "mrname" field. It is not always populated with a working = contact, but it should be. We should keep in mind that neither will every site = publish security.txt. For every server with a DNS name, one can find the zone's SOA record = via: dig -t SOA some.server.example. this yields the SOA record in the answer section if = "some.server.example" is at a zone cut, or in the authority section if not. If for some reason the zone contact will not do, and a new "more = specific" record is needed, why not just publish the email addresses there? = What's the purpose of the extra indirection with hashes of "security.txt"? Coordinating the hash updates with updates on the server will not be = fun. I predict >50% of any published hashes would be wrong within a year of initial publication. There'd be no "pressure" to keep them up to date, until it is too late in a crisis. So, NO, the hashes in DNS approach is not viable for this. Put the data in one place or don't bother at all. --=20 Viktor. From nobody Thu Feb 15 20:31:46 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B4512AF6E for ; Thu, 15 Feb 2018 20:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 B7qRqTUvOYgJ for ; Thu, 15 Feb 2018 20:31:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 6991B127369 for ; Thu, 15 Feb 2018 20:31:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1emXgS-0000Ut-KP; Fri, 16 Feb 2018 04:31:41 +0000 Date: Thu, 15 Feb 2018 20:31:39 -0800 Message-ID: From: Randy Bush To: Yakov Shafranovich Cc: Security Area Advisory Group , Ed Overflow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] DNS hash proposal for security.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 04:31:45 -0000 > I specifically want to ask about the idea that Randy Bush mentioned - > generating a hash of the security.txt file i did a sha256 of the signed version, security.txt.sig > and placing it in DNS as a simpler way to verifying the integrity of > the file. This would also avoid a separate signature file, and mucking > around with certs. that's not unreasonable randy From nobody Thu Feb 15 20:32:39 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1966127369 for ; Thu, 15 Feb 2018 20:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 t9oamz_a2wE6 for ; Thu, 15 Feb 2018 20:32:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 80B1412D7EE for ; Thu, 15 Feb 2018 20:32:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1emXhK-0000VK-9N; Fri, 16 Feb 2018 04:32:34 +0000 Date: Thu, 15 Feb 2018 20:32:33 -0800 Message-ID: From: Randy Bush To: Viktor Dukhovni Cc: saag@ietf.org In-Reply-To: <85BBE78C-B14B-4CED-A3F1-1799856C7173@dukhovni.org> References: <85BBE78C-B14B-4CED-A3F1-1799856C7173@dukhovni.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] DNS hash proposal for security.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 04:32:38 -0000 > If DNS is simple and secure enough to publish the hash, why not dispense > with the hash, and just publish the data in the DNS? i like that the attacker would need to corrupt two data sources randy From nobody Thu Feb 15 20:40:27 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6112AF77 for ; Thu, 15 Feb 2018 20:40:26 -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, FREEMAIL_FROM=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 masXxC0ClP3U for ; Thu, 15 Feb 2018 20:40:25 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 DD3DE12AF6E for ; Thu, 15 Feb 2018 20:40:24 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id a7so1749789otk.9 for ; Thu, 15 Feb 2018 20:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3+PunPFl3PL3gp6TXrjIUhsimuLV90gTbFeGkXTOTPs=; b=rCvoJoKfO10vZoHiGijmfZTxs5JwTdXsb+SvbsG5iZErYv+uTuog7e4neNYz2QYcAT +eGJMt6I30xJUuROJwPmqw+1djJ7POtdAI86ElcZ2vGbZjXGcbTReZJStPMhFz6T0K62 UMcLZQNTktCGENSwzvY0qGsnLvMitaBDptKn7UT2cP1u8flVHZnB+LFJ4xFwNptP9lp/ 8zutGy5vd6qx/QzycZZMny4iOW2JUrEpo6UfX+LrZ34Jf5SA24yxrvGrlmX5wZhWTWPs HI2kKrgeBPD0vWoqvWEpVp0yQcCzrgJYWHsxqFqux6fMQmCZebS2l1l+Xd+U5vu7nohw Zn0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3+PunPFl3PL3gp6TXrjIUhsimuLV90gTbFeGkXTOTPs=; b=W0f9p+FdXqj4LLNLfUEy4l30dCF1J13CygVlHMbO8vLU+WDwJUkpbpBcd+u4XVvatM oikcOTcFzsjKK5/46kLHLN1wI29bi7vjQ5NuGlxH1kVZuNhsPCK9QDP7Lh+8sZlmbWgk KjjoPdaa0QmgOGT3xL75CE1u2b6g3qlK8otHo6n0SA7FB0LxhaMMH/LDLYnQC5V000LZ 3FVMk/m0tHYIdAe52k4VZaSGpI/xx0XhMHVmG8aoMklDbZoGkaOEdcp1UJm547UtOSgg FX8IwC/zSYg2b6Ra3JKn7fRMywwCrVbdwtBVU6x0p9UY7vVySd5HR6a34Xp/r1rTqRaO 90Fw== X-Gm-Message-State: APf1xPD1CocuFj6A52G0OyOiVBjG5R7Ra/RNmHM6WHTlYdJqIJdVOPB6 gRJVx6WeIHeSeGxbK8qi06+lL6skJrOQg5ZdbrU= X-Google-Smtp-Source: AH8x224e9UccqTwSop0awELrvfYvSlSvTmhdMUj+rKVUaqiJCpNAo3CYuzjNfieR8eAmhwuYwKd29RR3uBonWslQX08= X-Received: by 10.157.33.90 with SMTP id l26mr3707372otd.241.1518756024030; Thu, 15 Feb 2018 20:40:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Thu, 15 Feb 2018 20:40:22 -0800 (PST) In-Reply-To: References: <85BBE78C-B14B-4CED-A3F1-1799856C7173@dukhovni.org> From: Martin Thomson Date: Fri, 16 Feb 2018 15:40:22 +1100 Message-ID: To: Randy Bush Cc: Viktor Dukhovni , saag Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] DNS hash proposal for security.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 04:40:26 -0000 On Fri, Feb 16, 2018 at 3:32 PM, Randy Bush wrote: >> If DNS is simple and secure enough to publish the hash, why not dispense >> with the hash, and just publish the data in the DNS? > > i like that the attacker would need to corrupt two data sources It's still really only one here. If the attacker can write to DNS, then they can write A/AAAA records and TXT at _acme.. I guess that involves an active, ongoing attack, so it's still better than a single compromise. From nobody Thu Feb 15 22:48:03 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB0912D7E9 for ; Thu, 15 Feb 2018 22:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JQusiTDQg0z2 for ; Thu, 15 Feb 2018 22:48:00 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9D8124217 for ; Thu, 15 Feb 2018 22:47:59 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 190C47A3309 for ; Fri, 16 Feb 2018 06:47:59 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 16 Feb 2018 01:47:56 -0500 Content-Transfer-Encoding: 7bit Reply-To: saag@ietf.org Message-Id: References: <85BBE78C-B14B-4CED-A3F1-1799856C7173@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] DNS hash proposal for security.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 06:48:01 -0000 > On Feb 15, 2018, at 11:32 PM, Randy Bush wrote: > >> If DNS is simple and secure enough to publish the hash, why not dispense >> with the hash, and just publish the data in the DNS? > > i like that the attacker would need to corrupt two data sources May sound good in theory, but a complete non-starter in practice. Too much complexity for too little gain. Setting the bar too high is counter-productive. Let's not keep making the same sort of mistakes that required rfc7435 to dispel. -- Viktor. From nobody Thu Feb 15 23:11:27 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B3D124217 for ; Thu, 15 Feb 2018 23:11:26 -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 PPokKZ7rEHGQ for ; Thu, 15 Feb 2018 23:11:23 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 9F7BB120721 for ; Thu, 15 Feb 2018 23:11:23 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id d26so2698680qtk.10 for ; Thu, 15 Feb 2018 23:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CI8k5n/WfXElxHkwjoqNV5Js9PzY/8NSKlomy2K+GlU=; b=pJ+5XNj4O4yjoOc+U121Vj3TuWuauME/R+amVLb5cqidbWOBhEzxRDopODTegjhRM+ bEkK1MWfHrHB37Ww+kKClVDlzTEjO9epbD89mp5vOpFxvg//6BgbZFhE/BbGBCFdzk4G YM66sjAvyviGZPW6MU6f/im1tAYiI46T2hDNFct6GAtyvnwqi/G8XZ9XUYOQrjLiBHI3 YpxkskAI4Ab8sfcG0D7ZQyVqA/+l1JRim5b6f1/0wc3zXyms5r8vnlJ6ljjQzsWDDecY qNjV0EozWl6zDLJZSdiocwca4EpK/NTGTIHTMsbp8r7hxGbER/WkbpQUFfmGxMezvkSH eVNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CI8k5n/WfXElxHkwjoqNV5Js9PzY/8NSKlomy2K+GlU=; b=iDHlurQqDV9yC7SDgWvkmCyI+gPwNOln6jlGfyRUDqrlDI3R1B+s2GzkVmc21z2sma ea5Mtewfh5xQAwML5P5NEWIUvjfPcUOfnUrFK06TW7AGAASHyZ3kKrdmoqUt3J8EHSFA ng26GeVIeUXiZkBmg/WOPHqOL3UwUcT+owgP/IVIsxV+bq88ejOH4b7HtIfaDIwW3p8K /WxUp+JL3nuZfIRrggi5la8DtcpTpvyqbzJziDHp3Qj8fKygry2DPgPB8ivu61MG42Xj 7YxoUPrwsg08AaZhs9vlkwnURaLvaQyiudGTFnCb95YDY3M14sxwIagVeMkQ9OERv2Qw stcw== X-Gm-Message-State: APf1xPBBbTlUyR0+2tbGvMTmSs6xd5j7JBQ5ZZi96o0D1cfrSCBKCZil jOH7zJ3IGauEGFz/2ngaswKahu4HeodFYIR8LlP58Q== X-Google-Smtp-Source: AH8x224PG9mHKsiBxafKgul7fVBFvJ0bnzEpNAacEaHDUIzL0Q3mL/D6X4vdFrWKrbelLB0Frcucp7mQ1nqXM5y4l0I= X-Received: by 10.200.40.208 with SMTP id j16mr8295893qtj.331.1518765082564; Thu, 15 Feb 2018 23:11:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.225.71 with HTTP; Thu, 15 Feb 2018 23:11:22 -0800 (PST) From: denis bider Date: Fri, 16 Feb 2018 01:11:22 -0600 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="001a11407a523e5c0f05654f0d02" Archived-At: Subject: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 07:11:26 -0000 --001a11407a523e5c0f05654f0d02 Content-Type: text/plain; charset="UTF-8" Hey everyone, I originally asked this on the Curdle mailing list, where we made some progress updating SSH. I'm seeking advice about the SFTP situation, and I was pointed to SECDISPATCH, and hence SAAG where I understand this type of thing would be discussed. SFTP is a widely used internet protocol that exists in two main versions: SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also widely supported, but most v4 implementations now seem to include v6. A schism happened over a decade ago when OpenSSH refused to adopt SFTP enhancements to support non-Unix platforms. They argued version 3 has everything it needs, which it does on Unix. But from a non-Unix perspective, many others thought it's not good enough, and better support for other platforms is needed. Because of this, there wasn't consensus, and SFTP did not become an RFC. Now, the result is that SFTP is a major internet protocol, and anyone who wants to implement it needs to follow this for SFTP v3: https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02 ... and this for v6: https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 https://tools.ietf.org/html/draft-galb-filexfer-extensions-00 In addition, a number of details are unclear and not documented fully. For example, OpenSSH encodes some packets differently than SFTP v3 prescribes, and implementations of check-file extensions are not compatible in practice due to different implementation restrictions on their usage. I would think it worthwhile for SFTP to receive better treatment, and I think practical use justifies documenting both version 3 and version 6. Since both are widely used, I think it would be reasonable for this to be Standards track, not Informational. However, if I write a draft - or perhaps two drafts - I'm not sure who to turn to. Does documenting existing SFTP practice warrant creating a new working group? Might this be pursued under the SECDISPATCH or SAAG purview? Or perhaps another process? Additionally, I wonder - is this work that can be done without traveling to London, etc in person? I understand that's how IETF still does things for the time being, but from my perspective this greatly reduces the number of people who would be interested in participating in an otherwise useful endeavor (perhaps to zero). denis --001a11407a523e5c0f05654f0d02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey everyone,

I originally a= sked this on the Curdle mailing list, where we made some progress updating = SSH. I'm seeking advice about the SFTP situation, and I was pointed to = SECDISPATCH, and hence SAAG where I understand this type of thing would be = discussed.

SFTP is a widely used internet protocol= that exists in two main versions: SFTP v3 with OpenSSH extensions, and SFT= P v6. SFTP v4 is also widely supported, but most v4 implementations now see= m to include v6.

A schism happened over a decade a= go when OpenSSH refused to adopt SFTP enhancements to support non-Unix plat= forms. They argued version 3 has everything it needs, which it does on Unix= . But from a non-Unix perspective, many others thought it's not good en= ough, and better support for other platforms is needed. Because of this, th= ere wasn't consensus, and SFTP did not become an RFC.

Now, the result is that SFTP is a major internet protocol, and anyo= ne who wants to implement it needs to follow this for SFTP v3:

... and this for v6:



In addition, a number of details are unclear and not documented fu= lly. For example, OpenSSH encodes some packets differently than SFTP v3 pre= scribes, and implementations of check-file extensions are not compatible in= practice due to different implementation restrictions on their usage.

I would think it worthwhile for SFTP to receive better= treatment, and I think practical use justifies documenting both version 3 = and version 6. Since both are widely used, I think it would be reasonable f= or this to be Standards track, not Informational.

= However, if I write a draft - or perhaps two drafts - I'm not sure who = to turn to. Does documenting existing SFTP practice warrant creating a new = working group? Might this be pursued under the SECDISPATCH or SAAG purview?= Or perhaps another process?

Additionally, I wonde= r - is this work that can be done without traveling to London, etc in perso= n? I understand that's how IETF still does things for the time being, b= ut from my perspective this greatly reduces the number of people who would = be interested in participating in an otherwise useful endeavor (perhaps to = zero).

denis

--001a11407a523e5c0f05654f0d02-- From nobody Fri Feb 16 08:42:32 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFBC124C27 for ; Fri, 16 Feb 2018 08:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 qMp3MpGwNUoq for ; Fri, 16 Feb 2018 08:42:29 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 162AF120454 for ; Fri, 16 Feb 2018 08:42:29 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id l34so1715647ywk.11 for ; Fri, 16 Feb 2018 08:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4TaygaxOyEHMVjLUz4162lqbDA5moMtg/cXtcqG3xKA=; b=w7EtsywT5//acg2ZZ/saGtPJZ8AN+IudDkxft6oLaZSDTn+CaOsWijI5sgj1GcLtL0 R+i0+juEizi+UgTVGV0PrRuaATjQQTQRs/UE/1I3RofJ9C7myCp9Ch2RcBvdn5UgHVDU B+jPSqZ0RfEZJkNePR8uVGn9SnkzpEUPnKpUIRwKW2NHexAEXV/r5f+QcCOlA+ZU/rJ6 1oQenlob8NL6uPKj1fsaP/zeFLKFkDAiRKuxUqZMNX9OCN8868GB6G5/wQWItYKPY4pA j1r/rYXfaIu0hsrBphPx0++h5qZ01qBrHP+XJgN4YVHW6Y+Q8jD1N6QH1lW/qkimfBRy bWYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4TaygaxOyEHMVjLUz4162lqbDA5moMtg/cXtcqG3xKA=; b=PHipR+4w01aNV2Fmg2d7rxqjyNjFAD3L8REL8WMgfwpih6Kv8z+pzPI8GvUp9UDYdj S/hpkCFfLpuz6dvnEQciw4zQwIH4kYhjuYg7R5ywafZsHRmyFhSw7yeafSM5ngA56Juy irKDuc2Qvc4LEUkH4Trez7i6BO3SNa23wf4mU6FnHDR4jUWqktKESgjmHjdLT0hNZ+l/ JcU09LHaKU2SCTcDsiFHmhRk59UwhPLfA/SocQkGvXLT/dXigTtFGGldYhfVUZY/MbG5 O9KEmn5XKHImwzVmgH5F3viLaEvYNZ/41J19Z44Dc93FSaSpZQ2ONPc5xJi7wzfDCxyo BZPA== X-Gm-Message-State: APf1xPBIEK3jybjxsh29+FB9S0HW8rF0QMiAMz6kE/fdgb3+nLo/VNqA EpU+hqdRXJ82/ijjRmcUZPTrSbBCT75GMftUDGaTog== X-Google-Smtp-Source: AH8x227JDvyy7ntIB7Xq9irPK4tZ6ayCEv5E3UePg4NEsle0ksHWkRezJ6vzA3HGYehHYeqqxnduADDAXR5TUU6vly8= X-Received: by 10.129.135.4 with SMTP id x4mr5171797ywf.102.1518799348251; Fri, 16 Feb 2018 08:42:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.114.10 with HTTP; Fri, 16 Feb 2018 08:41:47 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 16 Feb 2018 08:41:47 -0800 Message-ID: To: denis bider Cc: saag@ietf.org Content-Type: multipart/alternative; boundary="001a114f0e7ca356020565570733" Archived-At: Subject: Re: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 16:42:31 -0000 --001a114f0e7ca356020565570733 Content-Type: text/plain; charset="UTF-8" Hi Denis, I'm trying to get a handle on how much technical work there is to do here as opposed to just documentation work. Usually, the IETF expects to have change control of specifications is standardizes, but that seems perhaps not wanted here? -Ekr On Thu, Feb 15, 2018 at 11:11 PM, denis bider wrote: > Hey everyone, > > I originally asked this on the Curdle mailing list, where we made some > progress updating SSH. I'm seeking advice about the SFTP situation, and I > was pointed to SECDISPATCH, and hence SAAG where I understand this type of > thing would be discussed. > > SFTP is a widely used internet protocol that exists in two main versions: > SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also widely > supported, but most v4 implementations now seem to include v6. > > A schism happened over a decade ago when OpenSSH refused to adopt SFTP > enhancements to support non-Unix platforms. They argued version 3 has > everything it needs, which it does on Unix. But from a non-Unix > perspective, many others thought it's not good enough, and better support > for other platforms is needed. Because of this, there wasn't consensus, and > SFTP did not become an RFC. > > Now, the result is that SFTP is a major internet protocol, and anyone who > wants to implement it needs to follow this for SFTP v3: > > https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02 > > ... and this for v6: > > https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 > > https://tools.ietf.org/html/draft-galb-filexfer-extensions-00 > > In addition, a number of details are unclear and not documented fully. For > example, OpenSSH encodes some packets differently than SFTP v3 prescribes, > and implementations of check-file extensions are not compatible in practice > due to different implementation restrictions on their usage. > > I would think it worthwhile for SFTP to receive better treatment, and I > think practical use justifies documenting both version 3 and version 6. > Since both are widely used, I think it would be reasonable for this to be > Standards track, not Informational. > > However, if I write a draft - or perhaps two drafts - I'm not sure who to > turn to. Does documenting existing SFTP practice warrant creating a new > working group? Might this be pursued under the SECDISPATCH or SAAG purview? > Or perhaps another process? > > Additionally, I wonder - is this work that can be done without traveling > to London, etc in person? I understand that's how IETF still does things > for the time being, but from my perspective this greatly reduces the number > of people who would be interested in participating in an otherwise useful > endeavor (perhaps to zero). > > denis > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --001a114f0e7ca356020565570733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,

I'm trying to get a handl= e on how much technical work there is to do here as opposed to just documen= tation work. Usually, the IETF expects to have change control of specificat= ions is standardizes, but that seems perhaps not wanted here?
-Ekr


<= div class=3D"gmail_quote">On Thu, Feb 15, 2018 at 11:11 PM, denis bider <denisbider.ietf@gmail.com> wrote:
Hey everyone,

= I originally asked this on the Curdle mailing list, where we made some prog= ress updating SSH. I'm seeking advice about the SFTP situation, and I w= as pointed to SECDISPATCH, and hence SAAG where I understand this type of t= hing would be discussed.

SFTP is a widely used int= ernet protocol that exists in two main versions: SFTP v3 with OpenSSH exten= sions, and SFTP v6. SFTP v4 is also widely supported, but most v4 implement= ations now seem to include v6.

A schism happened o= ver a decade ago when OpenSSH refused to adopt SFTP enhancements to support= non-Unix platforms. They argued version 3 has everything it needs, which i= t does on Unix. But from a non-Unix perspective, many others thought it'= ;s not good enough, and better support for other platforms is needed. Becau= se of this, there wasn't consensus, and SFTP did not become an RFC.

Now, the result is that SFTP is a major internet prot= ocol, and anyone who wants to implement it needs to follow this for SFTP v3= :


... and this for v6:=


http= s://tools.ietf.org/html/draft-galb-filexfer-extensions-00

In addition, a number of details are unclear and not = documented fully. For example, OpenSSH encodes some packets differently tha= n SFTP v3 prescribes, and implementations of check-file extensions are not = compatible in practice due to different implementation restrictions on thei= r usage.

I would think it worthwhile for SFTP to r= eceive better treatment, and I think practical use justifies documenting bo= th version 3 and version 6. Since both are widely used, I think it would be= reasonable for this to be Standards track, not Informational.
However, if I write a draft - or perhaps two drafts - I'm = not sure who to turn to. Does documenting existing SFTP practice warrant cr= eating a new working group? Might this be pursued under the SECDISPATCH or = SAAG purview? Or perhaps another process?

Addition= ally, I wonder - is this work that can be done without traveling to London,= etc in person? I understand that's how IETF still does things for the = time being, but from my perspective this greatly reduces the number of peop= le who would be interested in participating in an otherwise useful endeavor= (perhaps to zero).

denis


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


--001a114f0e7ca356020565570733-- From nobody Fri Feb 16 09:01:38 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659ED124C27 for ; Fri, 16 Feb 2018 09:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.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 uGOgSwDnvoJT for ; Fri, 16 Feb 2018 09:01:33 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (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 7CBAB120454 for ; Fri, 16 Feb 2018 09:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mW9NdSXNZ3TXhQU/6agKSaZmBg3JO1h+i1ybugAw9iA=; b=EMpxfteidku0DFQZFL5SgC/pMV wroP+myOgDlm0b6l0LETQjgT6cZLkfuuwCMvfgRO5St4lP6uayI7Za/pDhA4t7qPKH65eL91xtcKJ P132vbVp/kXJxQxr19GRzVghXPxIEQj95hHXybbgVMCMPQHPWwBV1BQsHKkcmo7ZA3zU=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1emjO8-0007Md-6n; Fri, 16 Feb 2018 17:01:32 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id EA3307A01F5; Fri, 16 Feb 2018 12:01:30 -0500 (EST) Date: Fri, 16 Feb 2018 12:01:30 -0500 From: Theodore Ts'o To: denis bider Cc: saag@ietf.org Message-ID: <20180216170130.GB12890@thunk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 17:01:35 -0000 On Fri, Feb 16, 2018 at 01:11:22AM -0600, denis bider wrote: > > SFTP is a widely used internet protocol that exists in two main versions: > SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also widely > supported, but most v4 implementations now seem to include v6. Is this list of SFTP implementations accurate? If not, could you point at more comprehensive list? Looking at the list I was able to find, it doesn't appear to support hte claim that SFTP v4 or v6 are widely deployed. https://www.greenend.org.uk/rjk/sftp/sftpimpls.html Cheers, - Ted From nobody Mon Feb 19 22:06:50 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245DC126CB6 for ; Mon, 19 Feb 2018 22:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 imLyVBNjb1C1 for ; Mon, 19 Feb 2018 22:06:46 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 684FD124235 for ; Mon, 19 Feb 2018 22:06:46 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id c7so652061qtn.3 for ; Mon, 19 Feb 2018 22:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=dgfgwDx82py7rvtW18lThi4h3CC7s3SfzNfgCLN1gec=; b=Tg9OS9FU9D2vlYTRSGyYeq6YsfJ3pq4mv+EH+g2LW2K2tE80P+lljoEEFdhdZY1yK1 ZTJ/LxN9hSvx3Y+fvnRTUguW9Mh2k9u0d3A5BmlReGICtRZMe1ZfF/4+a8EDTnuBdAC3 POy6WVwnjTBkHeRTiGB5FcBoVRSEaSfzOKeJwmv9/fu4RBxPwAFWEQi2/1FAtLpPboxO mEjSEJVI8Bb5FxutDtqlKLSmRRJyNRcOKW7yiM6wcjiGxgO/r2y7eU3pSBJBS+JDks5/ 9+I5VnmzCtb1y4xkJKbKSjtY+7THez1SLt7SfyuyYnHi/gV2u2o9WHRDcZTmoXY536Jn JgKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=dgfgwDx82py7rvtW18lThi4h3CC7s3SfzNfgCLN1gec=; b=RyLeOXuFeuVYNtOps96SvNq8ryuaeXOuZUOWwVKAuDPJcuWO09CjP99rUuunoakIjE hTNmx3nBEGOkIIpmwjyesR+DdJBGmQbIK6XKwiJTplTVq5ggeUCgZz/yeFfzjIn/+mRq yUb1da4U/RxEj3YZF4+Q6K8Q/yaCc2eFpruzpyyDZ8dx69KI+P4qDr5x8jjHqJYYbWah RbRajr/iaeqHCw7qoXcdQmLR1Chhx0bNWUR76T6OYw0QcAgNS2gHIiVJf5l0UsB/jS5D yQSld+lAekDqJPR1Q10ogwC6POoSDqeqjEj3a/3CsAYtcdQYT0QidR8eXs5ldFgdzQSU MgcA== X-Gm-Message-State: APf1xPB4a/fp1egswc2JYvM2X3NC8rV8pZVBajHv7vT8xEnXu0SkpEoN bnDqiVPwIydVJL6fBXSxl0HWwmWnFbDrYRFr8pf3ZA== X-Google-Smtp-Source: AH8x227Q+3u5dZvidU52j3KQ3n4ZyAl7cKtIn85o+cZ9LuzYxArHy5f8NhidexX+P6m89Qa55FYCa+9ofglbb5SThHg= X-Received: by 10.200.40.252 with SMTP id j57mr15025593qtj.331.1519106805520; Mon, 19 Feb 2018 22:06:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.225.71 with HTTP; Mon, 19 Feb 2018 22:06:45 -0800 (PST) In-Reply-To: <20180216170130.GB12890@thunk.org> References: <20180216170130.GB12890@thunk.org> From: denis bider Date: Tue, 20 Feb 2018 00:06:45 -0600 Message-ID: Cc: saag@ietf.org Content-Type: multipart/alternative; boundary="001a114034c284de3f05659e9d9e" Archived-At: Subject: Re: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 06:06:48 -0000 --001a114034c284de3f05659e9d9e Content-Type: text/plain; charset="UTF-8" This list is very incomplete. I see no mention of a variety of commercial implementations. Tectia (the original) is not even mentioned. There's many more vendors of SFTP clients, servers and libraries than what's listed here. Off the top of my mind, SFTP v6 implementations that are not listed include Bitvise (our own, SFTP 3-6) and VanDyke (SFTP 3-6). I checked Wikipedia, that's not very useful either, because random people keep coming and deleting other people's implementations from the articles. In practical use, SFTP v3 is of course the most common because that's what's in OpenSSH. I've heard feedback indicating that the open source people (OpenSSH, PuTTY, dropbear, etc) are contemplating banding together and making further extensions to SFTP v3 while ignoring SFTP v6. This is sad. It seems the schism continues. Group X has needs A, and does not care about addressing the needs of group Y with needs B. :-/ On Fri, Feb 16, 2018 at 11:01 AM, Theodore Ts'o wrote: > On Fri, Feb 16, 2018 at 01:11:22AM -0600, denis bider wrote: > > > > SFTP is a widely used internet protocol that exists in two main versions: > > SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also widely > > supported, but most v4 implementations now seem to include v6. > > Is this list of SFTP implementations accurate? If not, could you > point at more comprehensive list? Looking at the list I was able to > find, it doesn't appear to support hte claim that SFTP v4 or v6 are > widely deployed. > > https://www.greenend.org.uk/rjk/sftp/sftpimpls.html > > Cheers, > > - Ted > --001a114034c284de3f05659e9d9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This list is very incomplete. I see no mention o= f a variety of commercial implementations. Tectia (the original) is not eve= n mentioned. There's many more vendors of SFTP clients, servers and lib= raries than what's listed here.

Off the top of my mind,= SFTP v6 implementations that are not listed include Bitvise (our own, SFTP= 3-6) and VanDyke (SFTP 3-6).

I checked Wikipedia, that'= s not very useful either, because random people keep coming and deleting ot= her people's implementations from the articles.

In pract= ical use, SFTP v3 is of course the most common because that's what'= s in OpenSSH.

I've heard feedback indicating that the op= en source people (OpenSSH, PuTTY, dropbear, etc) are contemplating banding = together and making further extensions to SFTP v3 while ignoring SFTP v6. T= his is sad. It seems the schism continues. Group X has needs A, and does no= t care about addressing the needs of group Y with needs B. :-/


On Fri, Feb 1= 6, 2018 at 11:01 AM, Theodore Ts'o <tytso@mit.edu> wrote:
On Fri, Feb 16, 2018 at 01= :11:22AM -0600, denis bider wrote:
>
> SFTP is a widely used internet protocol that exists in two main versio= ns:
> SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also widely > supported, but most v4 implementations now seem to include v6.

Is this list of SFTP implementations accurate?=C2=A0 If not, could y= ou
point at more comprehensive list?=C2=A0 Looking at the list I was able to find, it doesn't appear to support hte claim that SFTP v4 or v6 are
widely deployed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.greenend.= org.uk/rjk/sftp/sftpimpls.html

Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Ted

--001a114034c284de3f05659e9d9e-- From nobody Mon Feb 19 22:12:32 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29122126CC7 for ; Mon, 19 Feb 2018 22:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 GwgA-L2wgDDG for ; Mon, 19 Feb 2018 22:12:29 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 D63B0124235 for ; Mon, 19 Feb 2018 22:12:28 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id g2so15091312qkd.12 for ; Mon, 19 Feb 2018 22:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JCNm1ZU04D2Zgmuqbr2bst5ae0guVgF/tn1AAPifoE4=; b=G7ytoQ2tG2yS2eAjq93RApr/GOuwHn92A7nbYc22mHqgaJ0lvOubfrapYbue1OsZwL TFvTqfnxNx32bEvP2iyvHwzwYV9CW0Xg8sSQ9aUEkFFm/Wdb3R/7GEJbj03WijnG893e qYY6gobBOxRXHEjtpk18fIfE9g3cLWiIxk/e9WD0VfIJWVpAqaLgoUUU6AG3zcGjZ76w T23WgUrjIU9e7oWkwnJQSuEVLfaV2P3rCEHyxN2vleo00lavri8O24EzySHZf5Aw2ku5 Yqti1GoQshR9rPx8atQi7XNhuJQGVpR0TcyCMPp08DJXvuc+tDpzNCO6p8FryJ2iVIMb MW8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JCNm1ZU04D2Zgmuqbr2bst5ae0guVgF/tn1AAPifoE4=; b=HQYgyxVE3h3FEDS9hi2VtEnlnSLuuUL+QS/17W3Z74SDM2n0Hwomwm6HcAhquqCosB sscjm8GGrfPLlmyP0RgkO5pTPToyQDgHs8siBtMHDJ1nI7HE45RhRKdvo7t1pJMkKnpE 64Qq0i8CG8U/4Vs0GSVQlejz2n/JnpE2gRCQAQuii8TLcJwMfY39+Vjq6vvFIZUrzznd pWlqwYlND//MgdMT6bJeoPlOlN5Tj8UNavzjYyYm+iDvMH9xdG5am8j2FyhhtGK2EKtN zZjfEqK33uS2vb6f2fum53kmVDCajnL1XI0vid7KPT3hd+ZI1489M67UfrHRiH6XkzzV jvag== X-Gm-Message-State: APf1xPDuur72aWmCgoph0AfYWTBm3lpMDZ7zAPRAGlggFUvGZzhVsOPS IpB1ZGKDYXnZit2bG63FKk6+tO+5M0zAHXxqAnM= X-Google-Smtp-Source: AH8x224JajmOQEIxu0mBdUXe4fopWu2SX5RoM8w9H0HNOfLeLp/z/sGW7DnBi2wSlZGc/8ab+NcdBdrVqNwJGIq7SQk= X-Received: by 10.55.26.69 with SMTP id a66mr28251377qka.146.1519107148045; Mon, 19 Feb 2018 22:12:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.225.71 with HTTP; Mon, 19 Feb 2018 22:12:27 -0800 (PST) In-Reply-To: References: From: denis bider Date: Tue, 20 Feb 2018 00:12:27 -0600 Message-ID: To: Eric Rescorla Cc: saag@ietf.org Content-Type: multipart/alternative; boundary="001a1147a654ef645305659eb1d3" Archived-At: Subject: Re: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 06:12:31 -0000 --001a1147a654ef645305659eb1d3 Content-Type: text/plain; charset="UTF-8" I can confirm that if this work were to be done, it would need to begin by documenting the existing. In this sense, there is not much leeway in what to express, but there is leeway in how to express it. On a protocol level, there would be leeway in new extensions, as well as existing features that currently don't work well between implementations. In particular, I think "check-file" extensions have turned out to be under-specified and further standardization is needed. On Fri, Feb 16, 2018 at 10:41 AM, Eric Rescorla wrote: > Hi Denis, > > I'm trying to get a handle on how much technical work there is to do here > as opposed to just documentation work. Usually, the IETF expects to have > change control of specifications is standardizes, but that seems perhaps > not wanted here? > > -Ekr > > > On Thu, Feb 15, 2018 at 11:11 PM, denis bider > wrote: > >> Hey everyone, >> >> I originally asked this on the Curdle mailing list, where we made some >> progress updating SSH. I'm seeking advice about the SFTP situation, and I >> was pointed to SECDISPATCH, and hence SAAG where I understand this type of >> thing would be discussed. >> >> SFTP is a widely used internet protocol that exists in two main versions: >> SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also widely >> supported, but most v4 implementations now seem to include v6. >> >> A schism happened over a decade ago when OpenSSH refused to adopt SFTP >> enhancements to support non-Unix platforms. They argued version 3 has >> everything it needs, which it does on Unix. But from a non-Unix >> perspective, many others thought it's not good enough, and better support >> for other platforms is needed. Because of this, there wasn't consensus, and >> SFTP did not become an RFC. >> >> Now, the result is that SFTP is a major internet protocol, and anyone who >> wants to implement it needs to follow this for SFTP v3: >> >> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02 >> >> ... and this for v6: >> >> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 >> >> https://tools.ietf.org/html/draft-galb-filexfer-extensions-00 >> >> In addition, a number of details are unclear and not documented fully. >> For example, OpenSSH encodes some packets differently than SFTP v3 >> prescribes, and implementations of check-file extensions are not compatible >> in practice due to different implementation restrictions on their usage. >> >> I would think it worthwhile for SFTP to receive better treatment, and I >> think practical use justifies documenting both version 3 and version 6. >> Since both are widely used, I think it would be reasonable for this to be >> Standards track, not Informational. >> >> However, if I write a draft - or perhaps two drafts - I'm not sure who to >> turn to. Does documenting existing SFTP practice warrant creating a new >> working group? Might this be pursued under the SECDISPATCH or SAAG purview? >> Or perhaps another process? >> >> Additionally, I wonder - is this work that can be done without traveling >> to London, etc in person? I understand that's how IETF still does things >> for the time being, but from my perspective this greatly reduces the number >> of people who would be interested in participating in an otherwise useful >> endeavor (perhaps to zero). >> >> denis >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >> > --001a1147a654ef645305659eb1d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can confirm that if this work were to be done, it w= ould need to begin by documenting the existing. In this sense, there is not= much leeway in what to express, but there is leeway in how to express it.<= /div>

On a protocol level, there would be leeway in new = extensions, as well as existing features that currently don't work well= between implementations. In particular, I think "check-file" ext= ensions have turned out to be under-specified and further standardization i= s needed.

On Fri, Feb 16, 2018 at 10:41 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:
Hi Denis,
<= br>
I'm trying to get a handle on how much technical work the= re is to do here as opposed to just documentation work. Usually, the IETF e= xpects to have change control of specifications is standardizes, but that s= eems perhaps not wanted here?

-Ekr

<= /div>

<= div class=3D"h5">On Thu, Feb 15, 2018 at 11:11 PM, denis bider <de= nisbider.ietf@gmail.com> wrote:
Hey everyone,=

I originally asked this on the Curdle mailing lis= t, where we made some progress updating SSH. I'm seeking advice about t= he SFTP situation, and I was pointed to SECDISPATCH, and hence SAAG where I= understand this type of thing would be discussed.

SFTP is a widely used internet protocol that exists in two main versions: = SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also widely suppor= ted, but most v4 implementations now seem to include v6.

A schism happened over a decade ago when OpenSSH refused to adopt SF= TP enhancements to support non-Unix platforms. They argued version 3 has ev= erything it needs, which it does on Unix. But from a non-Unix perspective, = many others thought it's not good enough, and better support for other = platforms is needed. Because of this, there wasn't consensus, and SFTP = did not become an RFC.

Now, the result is that SFT= P is a major internet protocol, and anyone who wants to implement it needs = to follow this for SFTP v3:


... and this for v6:


=

In addition, a number of de= tails are unclear and not documented fully. For example, OpenSSH encodes so= me packets differently than SFTP v3 prescribes, and implementations of chec= k-file extensions are not compatible in practice due to different implement= ation restrictions on their usage.

I would think i= t worthwhile for SFTP to receive better treatment, and I think practical us= e justifies documenting both version 3 and version 6. Since both are widely= used, I think it would be reasonable for this to be Standards track, not I= nformational.

However, if I write a draft - or per= haps two drafts - I'm not sure who to turn to. Does documenting existin= g SFTP practice warrant creating a new working group? Might this be pursued= under the SECDISPATCH or SAAG purview? Or perhaps another process?

Additionally, I wonder - is this work that can be done wi= thout traveling to London, etc in person? I understand that's how IETF = still does things for the time being, but from my perspective this greatly = reduces the number of people who would be interested in participating in an= otherwise useful endeavor (perhaps to zero).

denis


_____________________________________= __________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag



--001a1147a654ef645305659eb1d3-- From nobody Mon Feb 19 22:48:52 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02566126D74 for ; Mon, 19 Feb 2018 22:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 uXV9Bp6XZ-2g for ; Mon, 19 Feb 2018 22:48:48 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 666FD124235 for ; Mon, 19 Feb 2018 22:48:48 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id t13so11861637qkj.13 for ; Mon, 19 Feb 2018 22:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OrgjNdBmwuCxW3ek3f1TJhPw1moEtlHYNtuJaXCRVQE=; b=Xm/jHmv1aHlbGbbxbhmz0du7ZFSHwFsO95Zai4bwv97qBUjy6cM/V/KyG2YVo0ZNlM YpbiW3KAuBe/x845oCwWTjyjwaXJ2jXk7iPx47fV7yAZEtYwfCbu3gO216eJmQ8VCUE7 KncNy/fGOjj4dNpSVx7qQlL31VY51yN9DeVNWkfIohlvQrNJCnA4LEprdVjl5wPpWBpd 29+CJqMYYXO/D7x7IUZu2zZTDJw0c46TNnnCbCBx/ds32scNmHjvwrcMMN6ZS4YEeXCM t/zeagmxHNGPUgxX2D3w2gImB0IZWaEEWOSscolEiUQgPszryqkwSDGScN2b8UqL1PJH 5HfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OrgjNdBmwuCxW3ek3f1TJhPw1moEtlHYNtuJaXCRVQE=; b=TOQoc8txgS0x4t2nWxJon+/2JWfsjXluzgVbIgC82QlQmfDtfk5WIMQunkQyJDcncy D6e2dxXkFc4nuzk5spzcNIHafm7ag0481qArqZMLXevPcS6F3PLINvLxB7Blw5+cwMIw wNqYp+CRRuSUy1n/nGb1t6qhmG9yfxFWi9+oaB7Ray/hrfzNY2FV0HR4b8l1/+agZ/Gp ogI1afyEBRHkqZl1ICLB8XI+x6O7G+RdzltDoey0GOnXpeb+Mir08KtwXUp3PswxQk8+ rHL6R9xUWtpYZgHUhpFpBRcucc6+n+/pNRheeTRlx2hRmL+mLPN8NNnywDElgG2hUmUU /zrw== X-Gm-Message-State: APf1xPBL6GT0QsABjTrNDWBmrP/HPC+7Bu15HpVBUcPVMKLuCtZRDjf8 qLhyqUgD6c4cSqF42bXxz4H+BGO9FT3/ITOOd+I= X-Google-Smtp-Source: AH8x2272sbdItB1OFqLxCcZAYmxarOaloXCNktVTC4Dtxi0lhKh7XK4IpOsa6nffRYHab9XYolh9CExS3QexyDLmpGE= X-Received: by 10.55.155.19 with SMTP id d19mr23601336qke.193.1519109327538; Mon, 19 Feb 2018 22:48:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.225.71 with HTTP; Mon, 19 Feb 2018 22:48:47 -0800 (PST) In-Reply-To: References: From: denis bider Date: Tue, 20 Feb 2018 00:48:47 -0600 Message-ID: To: Eric Rescorla Cc: saag@ietf.org Content-Type: multipart/alternative; boundary="94eb2c075118d7d0ae05659f331f" Archived-At: Subject: Re: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 06:48:51 -0000 --94eb2c075118d7d0ae05659f331f Content-Type: text/plain; charset="UTF-8" Adding to this, it seems clear there continue to be two camps that want to go in different extension directions while maintaining a compatible core. We could layer these into: - "SFTP lite". This is supported by the open source community that wants to keep things simple, not implement support for platforms they don't care about, not implement features they don't need. They don't care and don't want support for Windows ACLs, file attributes, file sharing modes, native text files on platforms with different text/binary representations. This community wants to work on more extensions for SFTP v3, but without adding v4+ features. - "SFTP full". This is supported by a mixture of open source and commercial implementations that want to provide features sought by users. If the user is connecting to a Windows server, these implementations allow manipulating ACLs, setting file attributes, having control over file sharing modes. When a platform has distinct text/binary representations, these implementations allow transferring textual files in a way that's convenient for the user. This community will want further work done on SFTP v6, but is also likely to incorporate new work on "SFTP lite". To the extent these versions develop orthogonally, I think it's fine having both. However, I worry that at some point the "SFTP lite" camp will add features that exist in "SFTP full", and will add them in an incompatible way. If progress is to be made, it appears it is desirable to: - Respect the wants of both camps. Work on both forks without sabotaging the other. - Clearly determine what work belongs in one fork ("SFTP lite") and what belongs in the other ("SFTP full"). - Work on both forks in the same standards body, to coordinate what goes where. On Tue, Feb 20, 2018 at 12:12 AM, denis bider wrote: > I can confirm that if this work were to be done, it would need to begin by > documenting the existing. In this sense, there is not much leeway in what > to express, but there is leeway in how to express it. > > On a protocol level, there would be leeway in new extensions, as well as > existing features that currently don't work well between implementations. > In particular, I think "check-file" extensions have turned out to be > under-specified and further standardization is needed. > > On Fri, Feb 16, 2018 at 10:41 AM, Eric Rescorla wrote: > >> Hi Denis, >> >> I'm trying to get a handle on how much technical work there is to do here >> as opposed to just documentation work. Usually, the IETF expects to have >> change control of specifications is standardizes, but that seems perhaps >> not wanted here? >> >> -Ekr >> >> >> On Thu, Feb 15, 2018 at 11:11 PM, denis bider >> wrote: >> >>> Hey everyone, >>> >>> I originally asked this on the Curdle mailing list, where we made some >>> progress updating SSH. I'm seeking advice about the SFTP situation, and I >>> was pointed to SECDISPATCH, and hence SAAG where I understand this type of >>> thing would be discussed. >>> >>> SFTP is a widely used internet protocol that exists in two main >>> versions: SFTP v3 with OpenSSH extensions, and SFTP v6. SFTP v4 is also >>> widely supported, but most v4 implementations now seem to include v6. >>> >>> A schism happened over a decade ago when OpenSSH refused to adopt SFTP >>> enhancements to support non-Unix platforms. They argued version 3 has >>> everything it needs, which it does on Unix. But from a non-Unix >>> perspective, many others thought it's not good enough, and better support >>> for other platforms is needed. Because of this, there wasn't consensus, and >>> SFTP did not become an RFC. >>> >>> Now, the result is that SFTP is a major internet protocol, and anyone >>> who wants to implement it needs to follow this for SFTP v3: >>> >>> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02 >>> >>> ... and this for v6: >>> >>> https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 >>> >>> https://tools.ietf.org/html/draft-galb-filexfer-extensions-00 >>> >>> In addition, a number of details are unclear and not documented fully. >>> For example, OpenSSH encodes some packets differently than SFTP v3 >>> prescribes, and implementations of check-file extensions are not compatible >>> in practice due to different implementation restrictions on their usage. >>> >>> I would think it worthwhile for SFTP to receive better treatment, and I >>> think practical use justifies documenting both version 3 and version 6. >>> Since both are widely used, I think it would be reasonable for this to be >>> Standards track, not Informational. >>> >>> However, if I write a draft - or perhaps two drafts - I'm not sure who >>> to turn to. Does documenting existing SFTP practice warrant creating a new >>> working group? Might this be pursued under the SECDISPATCH or SAAG purview? >>> Or perhaps another process? >>> >>> Additionally, I wonder - is this work that can be done without traveling >>> to London, etc in person? I understand that's how IETF still does things >>> for the time being, but from my perspective this greatly reduces the number >>> of people who would be interested in participating in an otherwise useful >>> endeavor (perhaps to zero). >>> >>> denis >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>> >>> >> > --94eb2c075118d7d0ae05659f331f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding to this, it seems clear there continue to be two ca= mps that want to go in different extension directions while maintaining a c= ompatible core. We could layer these into:

- "SFTP = lite".=C2=A0This is supported by the open source community that wants = to keep things simple, not implement support for platforms they don't c= are about, not implement features they don't need. They don't care = and don't want support for Windows ACLs, file attributes, file sharing = modes, native text files on platforms with different text/binary representa= tions. This community wants to work on more extensions for SFTP v3, but wit= hout adding v4+ features.

- "SFTP full".= This is supported by a mixture of open source and commercial implementatio= ns that want to provide features sought by users. If the user is connecting= to a Windows server, these implementations allow manipulating ACLs, settin= g file attributes, having control over file sharing modes. When a platform = has distinct text/binary representations, these implementations allow trans= ferring textual files in a way that's convenient for the user. This com= munity will want further work done on SFTP v6, but is also likely to incorp= orate new work on "SFTP lite".

To the ex= tent these versions develop orthogonally, I think it's fine having both= . However, I worry that at some point the "SFTP lite" camp will a= dd features that exist in "SFTP full", and will add them in an in= compatible way.

If progress is to be made, it appe= ars it is desirable to:

- Respect the wants of bot= h camps. Work on both forks without sabotaging the other.

- Clearly determine what work belongs in one fork ("SFTP lite&= quot;) and what belongs in the other ("SFTP full").
- Work on both forks in the same standards body, to coordinate = what goes where.



On Tue, Feb 20, 2018 at 12:12 AM, = denis bider <denisbider.ietf@gmail.com> wrote:
I can confirm that if th= is work were to be done, it would need to begin by documenting the existing= . In this sense, there is not much leeway in what to express, but there is = leeway in how to express it.

On a protocol level, = there would be leeway in new extensions, as well as existing features that = currently don't work well between implementations. In particular, I thi= nk "check-file" extensions have turned out to be under-specified = and further standardization is needed.

On= Fri, Feb 16, 2018 at 10:41 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
Hi Denis,

I'm trying to get a handle on how much technical work there is = to do here as opposed to just documentation work. Usually, the IETF expects= to have change control of specifications is standardizes, but that seems p= erhaps not wanted here?

-Ekr

<= /div>

On Thu, Feb 15, 2018 at 11:11 PM, denis bid= er <denisbider.ietf@gmail.com> wrote:
Hey everyone,

I originally = asked this on the Curdle mailing list, where we made some progress updating= SSH. I'm seeking advice about the SFTP situation, and I was pointed to= SECDISPATCH, and hence SAAG where I understand this type of thing would be= discussed.

SFTP is a widely used internet protoco= l that exists in two main versions: SFTP v3 with OpenSSH extensions, and SF= TP v6. SFTP v4 is also widely supported, but most v4 implementations now se= em to include v6.

A schism happened over a decade = ago when OpenSSH refused to adopt SFTP enhancements to support non-Unix pla= tforms. They argued version 3 has everything it needs, which it does on Uni= x. But from a non-Unix perspective, many others thought it's not good e= nough, and better support for other platforms is needed. Because of this, t= here wasn't consensus, and SFTP did not become an RFC.

Now, the result is that SFTP is a major internet protocol, and any= one who wants to implement it needs to follow this for SFTP v3:
<= br>

... and this for v6:


In addition, a number of details are unclear and not documented fu= lly. For example, OpenSSH encodes some packets differently than SFTP v3 pre= scribes, and implementations of check-file extensions are not compatible in= practice due to different implementation restrictions on their usage.

I would think it worthwhile for SFTP to receive better= treatment, and I think practical use justifies documenting both version 3 = and version 6. Since both are widely used, I think it would be reasonable f= or this to be Standards track, not Informational.

= However, if I write a draft - or perhaps two drafts - I'm not sure who = to turn to. Does documenting existing SFTP practice warrant creating a new = working group? Might this be pursued under the SECDISPATCH or SAAG purview?= Or perhaps another process?

Additionally, I wonde= r - is this work that can be done without traveling to London, etc in perso= n? I understand that's how IETF still does things for the time being, b= ut from my perspective this greatly reduces the number of people who would = be interested in participating in an otherwise useful endeavor (perhaps to = zero).

denis


_______________________________________________<= br> saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag




--94eb2c075118d7d0ae05659f331f-- From nobody Tue Feb 20 12:52:05 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD18812AAB6 for ; Tue, 20 Feb 2018 12:52:04 -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, 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 gPWgjdOw1uSK for ; Tue, 20 Feb 2018 12:52:03 -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 84084120725 for ; Tue, 20 Feb 2018 12:52:03 -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 w1KKq2wZ048983 for ; Tue, 20 Feb 2018 15:52:02 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w1KKq2wZ048983 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1519159922; bh=3U5jBIJbGCCRrfGrkuGAMjH3eToUsBYqC70QBXE5Vfc=; h=From:To:Subject:Date:From; b=EaVLCJG2MIifdc4+DuGzboejCEHg7NMIMbLQyEOf7k6HVJOGR5PNjEZddVgbysI74 SgCstq93CTQeGxpp69WLt3iZsgNtdRNNpxp4q4Ek1uI66OIoS4j0drTub81Mkp1Nx7 NiZV0SRREvueQANoNVHMTl2jMi8W3wVIuRI7kuTw= 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 w1KKpwVx036229 for ; Tue, 20 Feb 2018 15:51:59 -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.0361.001; Tue, 20 Feb 2018 15:51:58 -0500 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: Security Dispatch (SecDispatch) Mailing List Thread-Index: AdOqirNeFPA6C5TkRwedMsYu4rhtnA== Date: Tue, 20 Feb 2018 20:51:57 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC013752FCA0@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: [saag] Security Dispatch (SecDispatch) Mailing List X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 20:52:05 -0000 Hello! A mailing list has been established for Security Dispatch [0], a process to= consider proposals for new work in the Security area. If interested, join= the discussion. ** List Name: secdispatch ** Post to: secdispatch@ietf.org ** More information: https://www.ietf.org/mailman/listinfo/secdispatch ** Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dsecdispa= tch Regards, Roman and Richard [0] https://datatracker.ietf.org/wg/secdispatch/about/ From nobody Tue Feb 20 20:25:36 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49639126BF3 for ; Tue, 20 Feb 2018 20:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 2kkgwURqZNEh for ; Tue, 20 Feb 2018 20:25:33 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9CF120721 for ; Tue, 20 Feb 2018 20:25:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1B64920AEA; Tue, 20 Feb 2018 23:25:33 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 20 Feb 2018 23:25:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=af9NRN IUdtP7eFiEJTWWeNF2AM3I9fFpyJE7yeuMQ+0=; b=bpq+N9Wp0hSvGp9AkneuM3 ouNttoXzlUCnKgnRIPXiRPXOUGQT7gRPxNAWfDtxb7frErtOc+00BRC15BM5v5gC ymHZBtlWVNtECGOxxXnIW3xXY83F+Dl854hmf/eDcxtwZJZ61RSsvvV35GYzlOkH dEkIVLs348hTjKaqmG7pQtnipeeShbnfATEEsDIw71pFB+PSvR3HITO7i8jDVwg9 MBdR//EFgfilNLzXqMH7j4SUjs8NxWgf8w9IJfIDcDoP1nzArjyhhDMcfysk2Y3n 7gE6Dx3RVKzjgccrKNLRDCPxEv//6KZn8gLDv+UY0wzS56ipYXCFuL1ZuJ8f0ZjQ == X-ME-Sender: Received: from [192.168.1.65] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 5EB9B7E0ED; Tue, 20 Feb 2018 23:25:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Tue, 20 Feb 2018 23:25:31 -0500 Cc: Eric Rescorla , saag@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: denis bider X-Mailer: Apple Mail (2.1283) Archived-At: Subject: Re: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 04:25:35 -0000 I've been wondering for a long time if an approach like this could work. = Though I'd be tempted to call the common base something like "SFTP = core" rather than "lite" because "lite" can sound like the work is of = lesser importance when it's really of primary importance. Then I = wonder whether "SFTP extensions for Windows" and "SFTP extensions for = *IX systems" and perhaps "SFTP extensions for remote file access" could = be worthwhile. "core" should be the mandatory-to-implement set of = functions required for basic interoperability. "core" should seek to minimize incompatible changes from existing server = implementations, while also providing a reliable means by which a client = can discover and make optimum use of server capabilities. Keith On Feb 20, 2018, at 1:48 AM, denis bider wrote: > Adding to this, it seems clear there continue to be two camps that = want to go in different extension directions while maintaining a = compatible core. We could layer these into: >=20 > - "SFTP lite". This is supported by the open source community that = wants to keep things simple, not implement support for platforms they = don't care about, not implement features they don't need. They don't = care and don't want support for Windows ACLs, file attributes, file = sharing modes, native text files on platforms with different text/binary = representations. This community wants to work on more extensions for = SFTP v3, but without adding v4+ features. >=20 > - "SFTP full". This is supported by a mixture of open source and = commercial implementations that want to provide features sought by = users. If the user is connecting to a Windows server, these = implementations allow manipulating ACLs, setting file attributes, having = control over file sharing modes. When a platform has distinct = text/binary representations, these implementations allow transferring = textual files in a way that's convenient for the user. This community = will want further work done on SFTP v6, but is also likely to = incorporate new work on "SFTP lite". >=20 > To the extent these versions develop orthogonally, I think it's fine = having both. However, I worry that at some point the "SFTP lite" camp = will add features that exist in "SFTP full", and will add them in an = incompatible way. >=20 > If progress is to be made, it appears it is desirable to: >=20 > - Respect the wants of both camps. Work on both forks without = sabotaging the other. >=20 > - Clearly determine what work belongs in one fork ("SFTP lite") and = what belongs in the other ("SFTP full"). >=20 > - Work on both forks in the same standards body, to coordinate what = goes where. >=20 From nobody Tue Feb 20 21:16:08 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FDB12AF83 for ; Tue, 20 Feb 2018 21:16:05 -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 VSrTe7kEDYm0 for ; Tue, 20 Feb 2018 21:16:03 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 A0C9912708C for ; Tue, 20 Feb 2018 21:16:03 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id d8so550496qtm.0 for ; Tue, 20 Feb 2018 21:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qcaVxAt3o1kAxGWmz9RpTeHPddEZG6uOoBpW/OU1kLM=; b=YICHPi2F5q1pvV7bAy+3kRt7iSFaeVIYWmfp4mNOVesz2CIKA189gk1Ee81eWwSVq5 Kgyw6nPBSb40H1LRe4blxLS8YtGq03bamXX59Ve+30vHT0OgiVevYMQ+7VqbD9PT2PEF iKEjyHqVtorHSvttFVIxPRDOwfFb5Y5C/0BOW1s8nyffpfQQ8UNXbX/93wjjPtAE7DTC Xnp7Hfq9aPyEse9ur1PTW9lIUJ09DEsj+R2sC2lvy5X8B9chsljRm1GMVjyv3yW6PBq4 wNC5k0VcMD9wovL1QI2hDIwOMmWVw7PU3OTZXhtKVaT25Qpl5PUX0fTLkrF0NjE/R/d1 429g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qcaVxAt3o1kAxGWmz9RpTeHPddEZG6uOoBpW/OU1kLM=; b=QlRQOf1pIV2iurh7wWygZExsQS/97iB9VM75AE+l6JbXqHwZ+WtedleGwatNa+LBat vKqgXGCy65uw+1KXrB7s4UUrYXpkVlsVbrSEef34hT7/By+cRtbTdLCc2YeSa4dic8/n LTdfOQosIhKDtWg0bmzTTElZf3ZP1RiTlFtH6hGHC75G2uQEHgnL/TL8kMxGXvEyuYYe IubGWUinrOVqyhhj192XGYKaH7WomcG6HyZSC1YaykxO2p1NySwVAj9mf6olAjTOQOC6 6ugi1SRbYTOVy/PwbZVii+cqSte5ji7VcO4HORNHZQrn2letBzqVATggrrXVLi8uaw4B 71jQ== X-Gm-Message-State: APf1xPCRZF0lVnJneqNQFp18DpIJyANfZWVJqGhekZNCOP4JQAnDodG7 VeZLSwwg21rDWObmVLyxDMQP6oXSYhIqCFrn0Tw= X-Google-Smtp-Source: AH8x225tdR3MFQL/LciN/3YH3yDrlMORQLKJrCN6Vy9f69TqJuolktT7y5bHrxJROnsW+nfpi0x/MhFhFdOr2cN18ZY= X-Received: by 10.200.81.146 with SMTP id c18mr3294901qtn.224.1519190162787; Tue, 20 Feb 2018 21:16:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.225.71 with HTTP; Tue, 20 Feb 2018 21:16:02 -0800 (PST) In-Reply-To: References: From: denis bider Date: Tue, 20 Feb 2018 23:16:02 -0600 Message-ID: To: Keith Moore Cc: Eric Rescorla , saag@ietf.org Content-Type: multipart/alternative; boundary="f4f5e806dec0ffd2af0565b205a3" Archived-At: Subject: Re: [saag] How to: SFTP toward RFC? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 05:16:05 -0000 --f4f5e806dec0ffd2af0565b205a3 Content-Type: text/plain; charset="UTF-8" I think that sounds sensible. "Core" sounds fine to me and would likely be preferred by those who wish to implement that only. :-) I found another implementation of SFTP v4/v6 that I did not think of earlier. J2SSH implements SFTP v4 on server side, and SFTP v6 on the client. It is a very common library in the enterprise world, especially for custom Java applications that need to interact with SSH. I believe it's the go-to SSH library in the Java world. On Tue, Feb 20, 2018 at 10:25 PM, Keith Moore wrote: > I've been wondering for a long time if an approach like this could work. > Though I'd be tempted to call the common base something like "SFTP core" > rather than "lite" because "lite" can sound like the work is of lesser > importance when it's really of primary importance. Then I wonder whether > "SFTP extensions for Windows" and "SFTP extensions for *IX systems" and > perhaps "SFTP extensions for remote file access" could be worthwhile. > "core" should be the mandatory-to-implement set of functions required for > basic interoperability. > > "core" should seek to minimize incompatible changes from existing server > implementations, while also providing a reliable means by which a client > can discover and make optimum use of server capabilities. > > Keith > > On Feb 20, 2018, at 1:48 AM, denis bider wrote: > > > Adding to this, it seems clear there continue to be two camps that want > to go in different extension directions while maintaining a compatible > core. We could layer these into: > > > > - "SFTP lite". This is supported by the open source community that wants > to keep things simple, not implement support for platforms they don't care > about, not implement features they don't need. They don't care and don't > want support for Windows ACLs, file attributes, file sharing modes, native > text files on platforms with different text/binary representations. This > community wants to work on more extensions for SFTP v3, but without adding > v4+ features. > > > > - "SFTP full". This is supported by a mixture of open source and > commercial implementations that want to provide features sought by users. > If the user is connecting to a Windows server, these implementations allow > manipulating ACLs, setting file attributes, having control over file > sharing modes. When a platform has distinct text/binary representations, > these implementations allow transferring textual files in a way that's > convenient for the user. This community will want further work done on SFTP > v6, but is also likely to incorporate new work on "SFTP lite". > > > > To the extent these versions develop orthogonally, I think it's fine > having both. However, I worry that at some point the "SFTP lite" camp will > add features that exist in "SFTP full", and will add them in an > incompatible way. > > > > If progress is to be made, it appears it is desirable to: > > > > - Respect the wants of both camps. Work on both forks without sabotaging > the other. > > > > - Clearly determine what work belongs in one fork ("SFTP lite") and what > belongs in the other ("SFTP full"). > > > > - Work on both forks in the same standards body, to coordinate what goes > where. > > > > --f4f5e806dec0ffd2af0565b205a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that sounds sensible. "Core" sounds fine= to me and would likely be preferred by those who wish to implement that on= ly. :-)

I found another implementation of SFTP v4/v6 tha= t I did not think of earlier. J2SSH implements SFTP v4 on server side, and = SFTP v6 on the client. It is a very common library in the enterprise world,= especially for custom Java applications that need to interact with SSH. I = believe it's the go-to SSH library in the Java world.

On Tue, Feb 20, 2018 at= 10:25 PM, Keith Moore <moore@network-heretics.com>= wrote:
I've been wondering for a lon= g time if an approach like this could work.=C2=A0 Though I'd be tempted= to call the common base something like "SFTP core" rather than &= quot;lite" because "lite" can sound like the work is of less= er importance when it's really of primary importance.=C2=A0 =C2=A0Then = I wonder whether "SFTP extensions for Windows" and "SFTP ext= ensions for *IX systems" and perhaps "SFTP extensions for remote = file access" could be worthwhile.=C2=A0 "core" should be the= mandatory-to-implement set of functions required for basic interoperabilit= y.

"core" should seek to minimize incompatible changes from existing= server implementations, while also providing a reliable means by which a c= lient can discover and make optimum use of server capabilities.

Keith

On Feb 20, 2018, at 1:48 AM, denis bider wrote:

> Adding to this, it seems clear there continue to be two camps that wan= t to go in different extension directions while maintaining a compatible co= re. We could layer these into:
>
> - "SFTP lite". This is supported by the open source communit= y that wants to keep things simple, not implement support for platforms the= y don't care about, not implement features they don't need. They do= n't care and don't want support for Windows ACLs, file attributes, = file sharing modes, native text files on platforms with different text/bina= ry representations. This community wants to work on more extensions for SFT= P v3, but without adding v4+ features.
>
> - "SFTP full". This is supported by a mixture of open source= and commercial implementations that want to provide features sought by use= rs. If the user is connecting to a Windows server, these implementations al= low manipulating ACLs, setting file attributes, having control over file sh= aring modes. When a platform has distinct text/binary representations, thes= e implementations allow transferring textual files in a way that's conv= enient for the user. This community will want further work done on SFTP v6,= but is also likely to incorporate new work on "SFTP lite".
>
> To the extent these versions develop orthogonally, I think it's fi= ne having both. However, I worry that at some point the "SFTP lite&quo= t; camp will add features that exist in "SFTP full", and will add= them in an incompatible way.
>
> If progress is to be made, it appears it is desirable to:
>
> - Respect the wants of both camps. Work on both forks without sabotagi= ng the other.
>
> - Clearly determine what work belongs in one fork ("SFTP lite&quo= t;) and what belongs in the other ("SFTP full").
>
> - Work on both forks in the same standards body, to coordinate what go= es where.
>


--f4f5e806dec0ffd2af0565b205a3-- From nobody Wed Feb 21 05:03:11 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F83012025C for ; Wed, 21 Feb 2018 05:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 UIsxH30RTROr for ; Wed, 21 Feb 2018 05:03:07 -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 3256C1200FC for ; Wed, 21 Feb 2018 05:03:06 -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 w1LD34OU006185 for ; Wed, 21 Feb 2018 08:03:04 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w1LD34OU006185 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1519218184; bh=3U5jBIJbGCCRrfGrkuGAMjH3eToUsBYqC70QBXE5Vfc=; h=From:To:Subject:Date:From; b=LW/DHdBAaGrpE1QdF1UT+xvAzVvsF0Hjai/gC6NJHLh6FWm2sVOvOa93u23PbRmgQ WSARJsOhnrly/Ue9X6BxW2C17B9mL3QmJ4JQRoG5AQDigrlrcDvU4bM7QD8tEexZ6D b6ce4G32VK29WnnUwvvm+RA15enQf3xYLAhEJQ2E= 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 w1LD2wII006602 for ; Wed, 21 Feb 2018 08:02:59 -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.0361.001; Wed, 21 Feb 2018 08:02:57 -0500 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: Security Dispatch (SecDispatch) Mailing List Thread-Index: AdOqirNeFPA6C5TkRwedMsYu4rhtnA== Date: Wed, 21 Feb 2018 13:02:57 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137532136@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: [saag] Security Dispatch (SecDispatch) Mailing List X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 13:03:09 -0000 Hello! A mailing list has been established for Security Dispatch [0], a process to= consider proposals for new work in the Security area. If interested, join= the discussion. ** List Name: secdispatch ** Post to: secdispatch@ietf.org ** More information: https://www.ietf.org/mailman/listinfo/secdispatch ** Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dsecdispa= tch Regards, Roman and Richard [0] https://datatracker.ietf.org/wg/secdispatch/about/ From nobody Fri Feb 23 02:42:33 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C65A1242EA for ; Fri, 23 Feb 2018 02:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 5nO522bOJOsc for ; Fri, 23 Feb 2018 02:42:30 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 3553E124235 for ; Fri, 23 Feb 2018 02:42:30 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1epAo8-0006fA-Hs for saag@ietf.org; Fri, 23 Feb 2018 11:42:28 +0100 Date: Fri, 23 Feb 2018 11:42:28 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: saag@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="37663318-1195930349-1519382442=:24956" Content-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 10:42:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-1195930349-1519382442=:24956 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Please be informed that another I-D of the pEp (Pretty Easy Privacy) series has just been published. You can find it on: https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ Abstract:    In public-key cryptography comparing the public keys' fingerprints of    the communication partners involved is vital to ensure that there is    no man-in-the-middle (MITM) attack on the communication channel.    Fingerprints normally consist of a chain of hexadecimal chars.    However, comparing hexadecimal strings is often impractical for    regular users and prone to misunderstandings.    To mitigate these challenges, this memo proposes the comparision of    trustwords as opposed to hexadecimal strings.  Trustwords are common    words in a natural language (e.g., English) to which the hexidecimal    strings are mapped to.  This makes the verification process more    natural. Anyways, we are looking forward to your feedback! All the best Bernie ---------- Forwarded message ---------- From: Date: Thu, Feb 22, 2018 at 9:17 AM Subject: I-D Action: draft-birk-pep-trustwords-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories.         Title           : pretty Easy privacy (pEp): Trustwords concept         Authors         : Volker Birk                           Hernani Marques                           Bernie Hoeneisen         Filename        : draft-birk-pep-trustwords-00.txt         Pages           : 6         Date            : 2018-02-22 Abstract:    In public-key cryptography comparing the public keys' fingerprints of    the communication partners involved is vital to ensure that there is    no man-in-the-middle (MITM) attack on the communication channel.    Fingerprints normally consist of a chain of hexadecimal chars.    However, comparing hexadecimal strings is often impractical for    regular users and prone to misunderstandings.    To mitigate these challenges, this memo proposes the comparision of    trustwords as opposed to hexadecimal strings.  Trustwords are common    words in a natural language (e.g., English) to which the hexidecimal    strings are mapped to.  This makes the verification process more    natural. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-birk-pep-trustwords-00 https://datatracker.ietf.org/doc/html/draft-birk-pep-trustwords-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --37663318-1195930349-1519382442=:24956-- From nobody Fri Feb 23 05:30:44 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E6E12E046 for ; Fri, 23 Feb 2018 05:30:42 -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, FREEMAIL_FROM=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 V8xVE-_ONT3a for ; Fri, 23 Feb 2018 05:30:41 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 CBCB112E045 for ; Fri, 23 Feb 2018 05:30:40 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id z12so14120611wrg.4 for ; Fri, 23 Feb 2018 05:30:40 -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=Tx9V9VwkL7afWhRFZOozDp9YxGli7OqgT/FLh2dqSsY=; b=W2m9aKvG8Kb9klPB2a/SVDKRj8htea7YPYbxyBaKJBuj81ItJ1ew/WkRFnZt84MNgi Io01V9hZDcmu+NgsUwwnH6i8xYHw/2H6lzTWgZe8iWxyCdJWM4lnd1Oou0whkT6yjCNU 6ip1C4c+s3SrG8A+GBTtsnoixlUoYUTD8wvvya5dVHyaYJ5cMzcyDtaRPX5axEBAaREb Kz9+ZCXlg8+q0G0dSIBJEmpPqws9foFhueuXa66k394M3Fc0wiOLEXJ09Bf5dqvx7ZVa AErOt1WhLXrOz2akGiAPCtMTakl5oM0gvjVuD57IjrKVWefJrSzryq84vgQhZj0J3FXd Hp/g== 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=Tx9V9VwkL7afWhRFZOozDp9YxGli7OqgT/FLh2dqSsY=; b=eeCHaNEFOaTOXBYsrLAmR9RPgUf1srbHGPD1cgpcJyHdP8TtcPS3kB5eEVUlszWppR 99PpXwn+uPvVQaqaQdc9pv+rDYIK/41BCeh2Mm76sopThJy7MEIeYwVOOKa2riU/qw8A 4Tg9yrdgxrgz/dRqJHWSYb4poj3C8CvdKjvIaN4McxxcjQJS9AB7XNNPj7axbrC2nGCl SIJAhlKKJMV0TuLHNpOMvZkzUBItF0WetD4+miTS7N3FdmXEhBop6rN3gLeTEQ5Rq2Hj o6eE1AOEGrk8iIWJiy2qqis834qqK5nQBf1Vk9VDl+wEwMR7XyvZ9m6dqcfUAUj7h8QG KVLQ== X-Gm-Message-State: APf1xPDGsBbQt6KFZCY/7skuvfIiiVkMeDdlqkT+vwx+JEymhm4CCiio CdgfL7mb0pKeYl/sM0/PgAL9Yqye X-Google-Smtp-Source: AH8x225xvdd3z6E7qMZCkJTWVyA5uZUwGIGEEik0/p32mHNswxibbXzWWEUHwVm4akJfDTuvY7fxfA== X-Received: by 10.223.156.193 with SMTP id h1mr1553891wre.281.1519392639367; Fri, 23 Feb 2018 05:30:39 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 62sm3078630wrf.24.2018.02.23.05.30.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 05:30:38 -0800 (PST) From: Yoav Nir Message-Id: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5BFEE2FC-70BA-4A6B-B6DE-8A6613EAF0AA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 23 Feb 2018 15:30:35 +0200 In-Reply-To: Cc: Security Area Advisory Group To: Bernie Hoeneisen References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 13:30:43 -0000 --Apple-Mail=_5BFEE2FC-70BA-4A6B-B6DE-8A6613EAF0AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Bernie. How is this better/different from RFC 1751? Thanks Yoav > On 23 Feb 2018, at 12:42, Bernie Hoeneisen = wrote: >=20 > Please be informed that another I-D of the pEp (Pretty Easy Privacy) = series has just been published. You can find it on: >=20 > https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ >=20 > Abstract: >=20 > In public-key cryptography comparing the public keys' fingerprints = of > the communication partners involved is vital to ensure that there = is > no man-in-the-middle (MITM) attack on the communication channel. > Fingerprints normally consist of a chain of hexadecimal chars. > However, comparing hexadecimal strings is often impractical for > regular users and prone to misunderstandings. >=20 > To mitigate these challenges, this memo proposes the comparision of > trustwords as opposed to hexadecimal strings. Trustwords are = common > words in a natural language (e.g., English) to which the = hexidecimal > strings are mapped to. This makes the verification process more > natural. >=20 > Anyways, we are looking forward to your feedback! >=20 > All the best > Bernie >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Thu, Feb 22, 2018 at 9:17 AM > Subject: I-D Action: draft-birk-pep-trustwords-00.txt > To: i-d-announce@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : pretty Easy privacy (pEp): Trustwords = concept > Authors : Volker Birk > Hernani Marques > Bernie Hoeneisen > Filename : draft-birk-pep-trustwords-00.txt > Pages : 6 > Date : 2018-02-22 >=20 > Abstract: > In public-key cryptography comparing the public keys' fingerprints = of > the communication partners involved is vital to ensure that there = is > no man-in-the-middle (MITM) attack on the communication channel. > Fingerprints normally consist of a chain of hexadecimal chars. > However, comparing hexadecimal strings is often impractical for > regular users and prone to misunderstandings. >=20 > To mitigate these challenges, this memo proposes the comparision of > trustwords as opposed to hexadecimal strings. Trustwords are = common > words in a natural language (e.g., English) to which the = hexidecimal > strings are mapped to. This makes the verification process more > natural. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-birk-pep-trustwords-00 > https://datatracker.ietf.org/doc/html/draft-birk-pep-trustwords-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_5BFEE2FC-70BA-4A6B-B6DE-8A6613EAF0AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlqQF3sACgkQuEkLFQpY zJnhvwf/fcjP1oOuSZlgX2BT1mUspT77zKsabY6peF14FNi4XFbo+J+dloOFlCL3 a5+IaOpsVbMFb99KH0pviciUMrshAnAJiOWaJDoeWXYLURzOy8WlhALLDWQ8UIIu EwoE3o/0LN2vzGUziXNPUysMm6PMhTVzqDVkKPqYJxdtzX5S40X6rRoGGXi6xbVv PRIXbFlUwfbUZ3z9PoIxta7pYlRRtxk8RxdcjeOFzKHGmMTdc80kkl/381MoCbHo RECj2nKWeHK/U/04OelJJqWaMWDa4BK0GJspAAbVhWYrf9syAnYEr5O6Mrca5TFj rh0thE1MbIeepxXA7nHPhFX5KzCIrQ== =SzTE -----END PGP SIGNATURE----- --Apple-Mail=_5BFEE2FC-70BA-4A6B-B6DE-8A6613EAF0AA-- From nobody Fri Feb 23 07:06:54 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F331275F4 for ; Fri, 23 Feb 2018 07:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 yY2BKlgVrQ2C for ; Fri, 23 Feb 2018 07:06:51 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 DBA2412711D for ; Fri, 23 Feb 2018 07:06:50 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1epEvv-0007jc-Tl; Fri, 23 Feb 2018 16:06:47 +0100 Date: Fri, 23 Feb 2018 16:06:47 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Yoav Nir cc: Security Area Advisory Group In-Reply-To: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> Message-ID: References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:06:53 -0000 Hi Yoav Thanks for you email. This work is different from RFC1751 in many ways, e.g.: 1) The target audience for this new work to use are ordinary human users, i.e. not technical stuff (or IT geeks) only. (Even grandma shall be able to use it.) 2) The hexadecimal (sub-)strings mapped into a single trustword are longer. This results in fewer trustwords to compare, but more trustwords in the dictionary. 3) The keywords are only read (and compared), but not written down by humans 4) The keywords will be available in many languages as opposed to English only Does this answer you question? All the best Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Fri, 23 Feb 2018, Yoav Nir wrote: > Hi, Bernie. > > How is this better/different from RFC 1751? > > Thanks > > Yoav > >> On 23 Feb 2018, at 12:42, Bernie Hoeneisen wrote: >> >> Please be informed that another I-D of the pEp (Pretty Easy Privacy) series has just been published. You can find it on: >> >> https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ >> >> Abstract: >> >> In public-key cryptography comparing the public keys' fingerprints of >> the communication partners involved is vital to ensure that there is >> no man-in-the-middle (MITM) attack on the communication channel. >> Fingerprints normally consist of a chain of hexadecimal chars. >> However, comparing hexadecimal strings is often impractical for >> regular users and prone to misunderstandings. >> >> To mitigate these challenges, this memo proposes the comparision of >> trustwords as opposed to hexadecimal strings. Trustwords are common >> words in a natural language (e.g., English) to which the hexidecimal >> strings are mapped to. This makes the verification process more >> natural. >> >> Anyways, we are looking forward to your feedback! >> >> All the best >> Bernie >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Thu, Feb 22, 2018 at 9:17 AM >> Subject: I-D Action: draft-birk-pep-trustwords-00.txt >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : pretty Easy privacy (pEp): Trustwords concept >> Authors : Volker Birk >> Hernani Marques >> Bernie Hoeneisen >> Filename : draft-birk-pep-trustwords-00.txt >> Pages : 6 >> Date : 2018-02-22 >> >> Abstract: >> In public-key cryptography comparing the public keys' fingerprints of >> the communication partners involved is vital to ensure that there is >> no man-in-the-middle (MITM) attack on the communication channel. >> Fingerprints normally consist of a chain of hexadecimal chars. >> However, comparing hexadecimal strings is often impractical for >> regular users and prone to misunderstandings. >> >> To mitigate these challenges, this memo proposes the comparision of >> trustwords as opposed to hexadecimal strings. Trustwords are common >> words in a natural language (e.g., English) to which the hexidecimal >> strings are mapped to. This makes the verification process more >> natural. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-birk-pep-trustwords-00 >> https://datatracker.ietf.org/doc/html/draft-birk-pep-trustwords-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > From nobody Fri Feb 23 08:48:09 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5912E039 for ; Fri, 23 Feb 2018 08:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 FldRkGkSOueK for ; Fri, 23 Feb 2018 08:48:05 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 DF529127136 for ; Fri, 23 Feb 2018 08:48:05 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1NGlRJp019817; Fri, 23 Feb 2018 16:48:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=5enXLF/BaXa0AU6/wqU2pafWG6/6rVmWwgFcyivDf20=; b=O+qzL3y0moHOIzTcJEIYi+K/ENWCKj3c/CwuYLP7l6gcvunTQYaxFoUmbYDiVHekp6o3 zoUhN6amGgJb068gOCJZgVEvP/6hQiLypr74fniftWGR29lcefqdNED87l6U60/8CWmC brc7ohlntWRQNOYLePk61K5LSPPvUSvZJq0p9nLJ8OhG2YK4009zRB4ZjtQSf81LQwCt x8uil9EMkDEbXRAGCN0qgVqKbUAHOdwTHeSS8iowgUEExVEb4AVubGh6pjd8iIrvIFX1 ZDLDXuk2W1pA6FKNOb38VauT42mNhxQYhDZ8tDz1Hd50qiH2Yx11oGB1rG7dNnkp3qZQ JA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2g9hf6ej4b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 16:48:00 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1NGjd2s000492; Fri, 23 Feb 2018 11:48:00 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2g6gm1sa0t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 11:47:59 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Feb 2018 10:47:58 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 23 Feb 2018 10:47:57 -0600 From: "Salz, Rich" To: Bernie Hoeneisen , "saag@ietf.org" Thread-Topic: [saag] I-D Action: draft-birk-pep-trustwords-00.txt Thread-Index: AQHTrMYO5MANjaRdiUSCkA0PQiRPXw== Date: Fri, 23 Feb 2018 16:47:57 +0000 Message-ID: <08D454B2-4F35-4428-AF75-369EF7EDDAE4@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.183] Content-Type: text/plain; charset="utf-8" Content-ID: <8E97F752B7E81E41BD59FA8E19832A53@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=755 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230208 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=709 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230208 Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 16:48:08 -0000 PiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaXJrLXBlcC10 cnVzdHdvcmRzLw0KICANCkNoZWNrIG91dCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MTc2MCBmb3IgYSBzaW1pbGFyIGRpY3Rpb25hcnkuDQoNCg0K From nobody Fri Feb 23 09:05:27 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C5A1241F3 for ; Fri, 23 Feb 2018 09:05: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 9aBtMvOEVUf3 for ; Fri, 23 Feb 2018 09:05:22 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 4596B1200B9 for ; Fri, 23 Feb 2018 09:05:22 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id 34so14787138wre.13 for ; Fri, 23 Feb 2018 09:05:22 -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=UWl0mvH3tjMzgBtCUD8uHhkFEU/BlAnO6cMDCJS8hDs=; b=WeiZNbAV45aLFLfVB3PvDD17QdFrp3VDLc0KeKdCX/8wy7N9mA6CtN55oNOxFwgoUU amEuROLRp1Oz+NIvJERyllWuexvNfg5sMKW3l5+QciSw+3GKvr0yaDu4mnf/W8R+IS/6 QKcqSKTfuareJ+WvU3nHsyaBrp51eMbMFupv3+5REPRJ7Tvamb+8rXX2MR20jwF13+tI B45tvqk8T4rcv/HnAYVS/lmn2+X9MNiUt4LvrGV9byZ8O6530lZvYLTjFYFrukJV1+cJ AlRShf0R6zTZP1Z3xRyk9MQfaTex1qLM2ob1jsbHIUoLmPippsJUO6eHMWXLFN/hdCSg WY+w== 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=UWl0mvH3tjMzgBtCUD8uHhkFEU/BlAnO6cMDCJS8hDs=; b=CfgtlxIYpCxjyYvEkKcMK7OO48f63+U0iiq6mfbBYFXotr1VQUthyPlHm7CaE4mBt9 qUzM4/W5+PTAmbzk4rSy/dGdgx1YXNNoc1Y7l56GBcy/tpyLLzAS4GCZw2A6gR9jMHcX WoWWvNf4/XxqOO967rD4ivvYcQzo31HIv/opIFxKB/o+n3tFlTOoipE4n4DVTpQQxckl ETQ+SISUVGYG8B92plxADy2dypAkOqaGhKxDbYrbch15RCblfejV/h60nos83Bt9ztR7 CauYv8IwrHjkfuLLJHQJHAPUJVW7tJpweOFAlRWxAcE+d5jFVFaNSckhOwqDfG64LGey 5x3w== X-Gm-Message-State: APf1xPDPs7SQz4gcrjuWRdJJluKiDFNTNGFvZIzxN724FmZZ2cLCeA+P M0WvhePFnG0hRmPhhsoXFl3hoOb+ X-Google-Smtp-Source: AH8x226MFby9HwfEMsERzJpY4zoNQyDghiJovctWU+iuJXPq3RM98sxoVVWg/45VTaknZkl6cYnbUQ== X-Received: by 10.223.192.72 with SMTP id c8mr2375089wrf.145.1519405520796; Fri, 23 Feb 2018 09:05:20 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id q15sm2980110wra.54.2018.02.23.09.05.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 09:05:19 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8546FDF2-FF3D-4D99-83A5-F526E1D623EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 23 Feb 2018 19:05:17 +0200 In-Reply-To: Cc: Security Area Advisory Group To: Bernie Hoeneisen References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 17:05:25 -0000 --Apple-Mail=_8546FDF2-FF3D-4D99-83A5-F526E1D623EA Content-Type: multipart/alternative; boundary="Apple-Mail=_F73ECD06-1AD5-4608-930C-CC6996E60ADF" --Apple-Mail=_F73ECD06-1AD5-4608-930C-CC6996E60ADF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. At a former employer we used the function described in RFC 1751 to show = a user the CA or server fingerprint so as to make sure that their VPN = client was connecting to the correct server. It would be used as part of = the instructions for the user: Type in =E2=80=9C192.0.2.5=E2=80=9D or = =E2=80=9Cvpnserver.example.com =E2=80=9D = at the server box, click =E2=80=9CConnect=E2=80=9D and you will see a = fingerprint field. Make sure it says =E2=80=9CTIDE ITCH SLOW REIN RULE = MOT=E2=80=9D. This has proved OK for ordinary non-technical users, but I can=E2=80=99t = be sure any of them ever compared the strings. It=E2=80=99s easier to = just click OK. Similarly for point #3, I don=E2=80=99t think either of = them calls for the user to write anything down, except in the = instructions from the administrator. BTW: even if you make sure your dictionary contains only innocuous words = (no swear words), the combinations sometimes can be open to = interpretations: HERO JAKE LAID JAIL BAIT GLAD can come out of the = algorithm in RFC 1751. Anyway, I think your draft should reference RFC 1751 and state these = differences. Yoav > On 23 Feb 2018, at 17:06, Bernie Hoeneisen = wrote: >=20 > Hi Yoav >=20 > Thanks for you email. >=20 > This work is different from RFC1751 in many ways, e.g.: >=20 > 1) The target audience for this new work to use are ordinary human = users, i.e. not technical stuff (or IT geeks) only. (Even grandma shall = be able to use it.) >=20 > 2) The hexadecimal (sub-)strings mapped into a single trustword are = longer. This results in fewer trustwords to compare, but more trustwords = in the dictionary. >=20 > 3) The keywords are only read (and compared), but not written down by = humans >=20 > 4) The keywords will be available in many languages as opposed to = English only >=20 > Does this answer you question? >=20 > All the best > Bernie >=20 > -- >=20 > http://ucom.ch/ > Modern Telephony Solutions and Tech Consulting for Internet Technology >=20 >=20 > On Fri, 23 Feb 2018, Yoav Nir wrote: >=20 >> Hi, Bernie. >>=20 >> How is this better/different from RFC 1751? >>=20 >> Thanks >>=20 >> Yoav >>=20 >>> On 23 Feb 2018, at 12:42, Bernie Hoeneisen = wrote: >>>=20 >>> Please be informed that another I-D of the pEp (Pretty Easy Privacy) = series has just been published. You can find it on: >>>=20 >>> https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ >>>=20 >>> Abstract: >>>=20 >>> In public-key cryptography comparing the public keys' fingerprints = of >>> the communication partners involved is vital to ensure that there = is >>> no man-in-the-middle (MITM) attack on the communication channel. >>> Fingerprints normally consist of a chain of hexadecimal chars. >>> However, comparing hexadecimal strings is often impractical for >>> regular users and prone to misunderstandings. >>>=20 >>> To mitigate these challenges, this memo proposes the comparision = of >>> trustwords as opposed to hexadecimal strings. Trustwords are = common >>> words in a natural language (e.g., English) to which the = hexidecimal >>> strings are mapped to. This makes the verification process more >>> natural. >>>=20 >>> Anyways, we are looking forward to your feedback! >>>=20 >>> All the best >>> Bernie >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: >>> Date: Thu, Feb 22, 2018 at 9:17 AM >>> Subject: I-D Action: draft-birk-pep-trustwords-00.txt >>> To: i-d-announce@ietf.org >>>=20 >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>=20 >>>=20 >>> Title : pretty Easy privacy (pEp): Trustwords = concept >>> Authors : Volker Birk >>> Hernani Marques >>> Bernie Hoeneisen >>> Filename : draft-birk-pep-trustwords-00.txt >>> Pages : 6 >>> Date : 2018-02-22 >>>=20 >>> Abstract: >>> In public-key cryptography comparing the public keys' fingerprints = of >>> the communication partners involved is vital to ensure that there = is >>> no man-in-the-middle (MITM) attack on the communication channel. >>> Fingerprints normally consist of a chain of hexadecimal chars. >>> However, comparing hexadecimal strings is often impractical for >>> regular users and prone to misunderstandings. >>>=20 >>> To mitigate these challenges, this memo proposes the comparision = of >>> trustwords as opposed to hexadecimal strings. Trustwords are = common >>> words in a natural language (e.g., English) to which the = hexidecimal >>> strings are mapped to. This makes the verification process more >>> natural. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-birk-pep-trustwords-00 >>> https://datatracker.ietf.org/doc/html/draft-birk-pep-trustwords-00 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>=20 >>=20 --Apple-Mail=_F73ECD06-1AD5-4608-930C-CC6996E60ADF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

At a = former employer we used the function described in RFC 1751 to show a = user the CA or server fingerprint so as to make sure that their VPN = client was connecting to the correct server. It would be used as part of = the instructions for the user:  Type in =E2=80=9C192.0.2.5=E2=80=9D = or =E2=80=9Cvpnserver.example.com=E2=80=9D at the server box, click = =E2=80=9CConnect=E2=80=9D and you will see a fingerprint field. Make = sure it says =E2=80=9CTIDE ITCH SLOW REIN RULE MOT=E2=80=9D.

This has proved OK for = ordinary non-technical users, but I can=E2=80=99t be sure any of them = ever compared the strings. It=E2=80=99s easier to just click OK. = Similarly for point #3, I don=E2=80=99t think either of them calls for = the user to write anything down, except in the instructions from the = administrator.

BTW: even if you make sure your dictionary contains only = innocuous words (no swear words), the combinations sometimes can be open = to interpretations: HERO JAKE LAID JAIL BAIT GLAD can come out of the = algorithm in RFC 1751.

Anyway, I think your draft should reference RFC 1751 and = state these differences.

Yoav

On 23 Feb 2018, at 17:06, = Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> wrote:

Hi = Yoav

Thanks for you email.

This work is different from RFC1751 in many ways, e.g.:

1) The target audience for this new work to = use are ordinary human users, i.e. not technical stuff (or IT geeks) = only. (Even grandma shall be able to use it.)

2) The hexadecimal (sub-)strings mapped into a single = trustword are longer. This results in fewer trustwords to compare, but = more trustwords in the dictionary.

3) The = keywords are only read (and compared), but not written down by humans

4) The keywords will be available in many = languages as opposed to English only

Does = this answer you question?

All the best
Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet = Technology


On Fri, 23 Feb = 2018, Yoav Nir wrote:

Hi, Bernie.

How is = this better/different from RFC 1751?

Thanks

Yoav

On 23 Feb 2018, at = 12:42, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> wrote:

Please be informed that another I-D of the pEp = (Pretty Easy Privacy) series has just been published. You can find it = on:

= https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/

Abstract:

=   In public-key cryptography comparing the public keys' = fingerprints of
  the communication partners = involved is vital to ensure that there is
  no = man-in-the-middle (MITM) attack on the communication channel.
  Fingerprints normally consist of a chain of = hexadecimal chars.
  However, comparing = hexadecimal strings is often impractical for
=   regular users and prone to misunderstandings.

  To mitigate these challenges, = this memo proposes the comparision of
=   trustwords as opposed to hexadecimal strings. =  Trustwords are common
  words in a = natural language (e.g., English) to which the hexidecimal
=   strings are mapped to.  This makes the verification = process more
  natural.

Anyways, we are looking forward to your feedback!

All the best
Bernie


---------- Forwarded message = ----------
From: <internet-drafts@ietf.org>
Date: Thu, Feb 22, 2018 at 9:17 AM
Subject: I-D = Action: draft-birk-pep-trustwords-00.txt
To: = i-d-announce@ietf.org



A New Internet-Draft is available from the on-line = Internet-Drafts
directories.


=        Title =           : pretty = Easy privacy (pEp): Trustwords concept
=        Authors =         : Volker Birk
=             &n= bsp;           &nbs= p;Hernani Marques
=             &n= bsp;           &nbs= p;Bernie Hoeneisen
=        Filename =        : = draft-birk-pep-trustwords-00.txt
=        Pages =           : 6
       Date =            : = 2018-02-22

Abstract:
=   In public-key cryptography comparing the public keys' = fingerprints of
  the communication partners = involved is vital to ensure that there is
  no = man-in-the-middle (MITM) attack on the communication channel.
  Fingerprints normally consist of a chain of = hexadecimal chars.
  However, comparing = hexadecimal strings is often impractical for
=   regular users and prone to misunderstandings.

  To mitigate these challenges, = this memo proposes the comparision of
=   trustwords as opposed to hexadecimal strings. =  Trustwords are common
  words in a = natural language (e.g., English) to which the hexidecimal
=   strings are mapped to.  This makes the verification = process more
  natural.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-birk-pep-trustwords-00
https://datatracker.ietf.org/doc/html/draft-birk-pep-trustwords= -00


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag



= --Apple-Mail=_F73ECD06-1AD5-4608-930C-CC6996E60ADF-- --Apple-Mail=_8546FDF2-FF3D-4D99-83A5-F526E1D623EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlqQSc0ACgkQuEkLFQpY zJlzhQgAs9y4tzzMtlOeSV9y+1wu7dG6xlpafKECg1EHE8vs/RsgR48UXoFcEx9S 4reyQNwPfkOCg/HCBBnlcqeeAE4gukCOaoUqWIJ6W1iWvtBAaQHw1OlLyHty2B92 CucIrM4vZjeZXiHoHBRs5MaYhjrLcLPhQ+kBxykopWz5RPg1wyU1Sq+/hGZIkcnu 7Sd5QHeyZAGEAS0dyu60jTXgUinLMSW3+t3hv/TW5hINFMndCXeMowz0+IOtG8B5 pt+s4swvTelUVWLyRdce5GVkJB1keB2TSabN5D0ff3lWBWj+M/8MHhPv10LsdTfy VNR6f3Q/8WjMdiuNttxu+hsKa92LFg== =xch9 -----END PGP SIGNATURE----- --Apple-Mail=_8546FDF2-FF3D-4D99-83A5-F526E1D623EA-- From nobody Fri Feb 23 10:45:26 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF1126C2F for ; Fri, 23 Feb 2018 10:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 iV4QxzYGb2tK for ; Fri, 23 Feb 2018 10:45:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C29126DEE for ; Fri, 23 Feb 2018 10:45:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7210420090 for ; Fri, 23 Feb 2018 13:52:51 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9338E80B14 for ; Fri, 23 Feb 2018 13:45:21 -0500 (EST) From: Michael Richardson To: Security Area Advisory Group In-Reply-To: References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 18:45:25 -0000 --=-=-= Content-Type: text/plain Bernie Hoeneisen wrote: > 4) The keywords will be available in many languages as opposed to English > only I guess if two people speak different languages, then a mapping could exist between languages? While some might think this is too trivial for the IETF, I am rather in favour such a specification. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqQYUEACgkQgItw+93Q 3WXDswf+IVkM33vYde6DCAEYiq2OmrAzVpNtGv5YMnkP7aHjEtA1LDViDpJhsBUV 4foZvkFZY9Pi9B+2riM51f0RasTWnEt9A4QqBS6yTCw81WH4IduYM1qN5yWUAmcp /zZH/rfZvIDyYIiEY+X8gRwIU1+eyVKpdhDvO+5528W5+2rKgL8GZqCa2KfZCMhT KcLC2Uoo4x1W6IabAk0sMM/ET+BgtH6VJr8Lkac/XteflRBw36waZB9Ae53NjXy2 Dnlotpkg9rbJAl5SyGHlKoRp3oZifBKzCwmcq+XDDXcb+YG06+VH4fpkG4rjjjqv qLhFRbMF8vtCBnP7G8pV6LJON1o5Nw== =EWoL -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 23 10:58:25 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204B812D7F8 for ; Fri, 23 Feb 2018 10:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=ihix2Jpk; dkim=pass (1024-bit key) header.d=yitter.info header.b=KDJTQbVL 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 bBjKa8hRF1Iz for ; Fri, 23 Feb 2018 10:58:22 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A907E126C2F for ; Fri, 23 Feb 2018 10:58:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id F2B24BE777 for ; Fri, 23 Feb 2018 18:57:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1519412271; bh=YGmmkVhPz6PeYQpwHiLZe2wDlTXWosPPf8XKmLOooaM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ihix2JpkxXvhRYy0i7tcMKVfl8kkejzT6lVM++sCgFAgxLvo8d21PYKs0uzWpMLxv bufH5gCWHYotN8lXKAYZtRmJ9KSGg9orSpuZZpiUZGKi4CZnfMWewSWfZ/Wj+6gJq6 7TM11OHwVMWfF7QGHSRMGjBrQ1NY0G5YegQ14GNA= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlN047kmR1XK for ; Fri, 23 Feb 2018 18:57:50 +0000 (UTC) Date: Fri, 23 Feb 2018 13:57:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1519412270; bh=YGmmkVhPz6PeYQpwHiLZe2wDlTXWosPPf8XKmLOooaM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KDJTQbVL1PGkX6H8DY852dVk+n1euNgeQoNV1dtXV6WhJVINH+z8IPdPdW8a6k/kw GePrf97b/cO4F3PFdmO9SHZNSXGbaWs1iOJzYara9e3EgkWuflmawZjqvmyo71gAjb xfvveujaBbt6r9WJ1uvq7K0v5bBvfHLEgW7DQNm0= From: Andrew Sullivan To: saag@ietf.org Message-ID: <20180223185748.75pdjo5yisoe24yc@mx4.yitter.info> References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> <10478.1519411521@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10478.1519411521@obiwan.sandelman.ca> Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 18:58:24 -0000 On Fri, Feb 23, 2018 at 01:45:21PM -0500, Michael Richardson wrote: > > Bernie Hoeneisen wrote: > > 4) The keywords will be available in many languages as opposed to English > > only > > I guess if two people speak different languages, then a mapping could exist > between languages? > > While some might think this is too trivial for the IETF, I am rather in > favour such a specification. I don't think it's too trivial. I think it's too hard. We can't even get people to review internationalization considerations for protcols we understand. Translating among languages strikes me as something some distance past our set of skills. I would not be opposed to setting up the registry for mappings to be generated by someone else, however. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Feb 23 12:56:07 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FC8124D68 for ; Fri, 23 Feb 2018 12:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 iZowMdWUV2Dl for ; Fri, 23 Feb 2018 12:56:00 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8732D126B72 for ; Fri, 23 Feb 2018 12:55:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id 677BD171C071 for ; Fri, 23 Feb 2018 21:55:56 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqB0i0T41QCR for ; Fri, 23 Feb 2018 21:55:53 +0100 (CET) Received: from [192.168.43.106] (171.225.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch [178.197.225.171]) by dragon.pibit.ch (Postfix) with ESMTPSA id 9DC9E171C05F for ; Fri, 23 Feb 2018 21:55:53 +0100 (CET) To: saag@ietf.org References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> <10478.1519411521@obiwan.sandelman.ca> <20180223185748.75pdjo5yisoe24yc@mx4.yitter.info> From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= Openpgp: id=31733E0C598D3A1CF70955D6CB5738652768F7E9 Message-ID: <7f0586de-6206-68e4-3bd4-880cbab9ed2d@pep.foundation> Date: Fri, 23 Feb 2018 21:55:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180223185748.75pdjo5yisoe24yc@mx4.yitter.info> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iNP3JyEq9UoV9si7yv8OnRL3bNO9vH4Fo" Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 20:56:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iNP3JyEq9UoV9si7yv8OnRL3bNO9vH4Fo Content-Type: multipart/mixed; boundary="OKk2XrdI3lowakdIxwSlZVlze2zZETUHK"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= To: saag@ietf.org Message-ID: <7f0586de-6206-68e4-3bd4-880cbab9ed2d@pep.foundation> Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> <10478.1519411521@obiwan.sandelman.ca> <20180223185748.75pdjo5yisoe24yc@mx4.yitter.info> In-Reply-To: <20180223185748.75pdjo5yisoe24yc@mx4.yitter.info> --OKk2XrdI3lowakdIxwSlZVlze2zZETUHK Content-Type: multipart/mixed; boundary="------------F5368C44A5AAF4B121B17703" Content-Language: de-CH This is a multi-part message in MIME format. --------------F5368C44A5AAF4B121B17703 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23.02.2018 19:57, Andrew Sullivan wrote: > I don't think it's too trivial. I think it's too hard. We can't even > get people to review internationalization considerations for protcols > we understand. Translating among languages strikes me as something > some distance past our set of skills. I agree to this: what we're doing for now in implementations already existing for opportunistic email encryption on pEp basis is to use the system-lang to determine the default words to be shown by default. Word lists exist in Catalan, Spanish, English, Turkish, French, German and Dutsch, cf. https://pep.foundation/dev/repos/pEpEngine/file/68b7fb2ad5b2/db If no Trustwords for system-lang exist, English is shown in fallback. The words for now are taken from LibreOffice and cleaned from swearwords (by native language speakers) in order to most probably less offense people (somewhat taking into consideration cultural contexts, sense for humour etc.). It's assumed that most people will compare words to people of their own region, i.e. in the system-lang. In any case, if people not speaking the sames languages use a phone line or a physical meeting to compare the Trustwords, they will need to agree on a wordlist of language (most probably English makes sense here) -- in pEp languages can easily be switched. For fallback or to retain full entropy, also fingerprints should exist in implementations using Trustwords for OpenPGP contexts. This also allows for interoperability with OpenPGP users not knowing anything about Trustwords. However, Trustwords -- as stated in the document -- can also be used for any other mapping where fingerprints play a role. --=20 p=E2=89=A1p foundation: https://pep.foundation/ --------------F5368C44A5AAF4B121B17703 Content-Type: application/pgp-keys; name="0xCB5738652768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xCB5738652768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjkEEwEIACMFAlcnOjUCGyMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDLVzhlJ2j36SSQEAC7L0ZgFNXZAsXUzDIj7ZcyG41jcIaF oBz+VyIz/72zsr7tR469bq9QulnEdhr5Zxa+sZauT+tktmehpQpkwAZRXb4jHawS MVGwzssKehUe+sN9rrkIKvFbKMHcL/ZUiaFKNL0dX/tbtA/lZGwMSGlE9x1BWPKX JrqiKUpvk278jFwkOfx+mzVSuuIcIn2o25BM6n4wxQnDizcES2Z9nXyYzSBagvW0 v2LsOEatYgCFoTxuO37uPHXL3NlhipRx5dfIxKjX5zr2DOxKcS7SPio9cGJ8Z5gB jfC3ByoZfQVmrR0lfIxZVtFTzR8my+fOLDhL5U+3RVbGHHHjzJZY03a8RUpcWsMr +lsogSH4h5z8QgkwfhTyBAUIcewHU5128dRG8m+wfTTHnQFCpmd0Ql3beRbAhN/e xQx5aJq81rPD7dunQtKB7iyiDpHjLWJ22aBr75GjSfF05Gr4LgLMFkATzrpnlXyR uLtZ0TTURWw+pximLJu/Smn5CKUClJayGOgp8a6bmNlxn6li6SZVoyu/S9RCUWTB z2dsv+iDjk/La7gcLxwrtkf2wFxvauaax5BjXoEnOAsD12wF3Snr6ymARh65rZ+C /HaiRpUXoUFIWUh0gRnJHa+EOxXq2wKBJul5toTlOEiqK93vVwKLlPgjiEY5NHEU 7zpE7skkXYqKhIkCPAQTAQgAJgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA BQJXJzpdAhkBAAoJEMtXOGUnaPfpktIP/iTLClFO8y+KN00z7cHxbistBKjkFlS+ Q4RzNmXQXgXMaB9pMvIbCP6Fm11q13GGT2MLm5gpoIBH50/fCXxWPGaeMRyKvv3p PDbSwm7J7hDP5H2yCGclkzs0NntiZXbOmLhFdZjsIhi2GnNSrUve6MOUM18p0ph3 f0+Ia3Ki3HaURLD4sGUJ12ig8tLI82nt+NaxEKCaD7b7KtV2XtMQ7RAVwax8to2m PBWzZReX4nMmqX8LNXhn1DFkCSGCl45umK7i39Em4+OYpLyWy3vMmKuGXA6uVenl WQbKuaw+Rer+MUOTM2sABfm5ffiNMGBO94JEGvgwSVUCmrqyBsZ846q+FTlJnapY /D63bIeINuX20TYxpzZSKh0U9sVKU6cd3koeH6CFYPLEICQBzDFZ7GTg9MJbAbGp y/P3klwdfHo8AcM6QIH7MIdfrkk5WljF1vz3FvWcGmoqmGRdrHt/JBsDw94p/d6G n/HWAX3gJvrF6+BTDUZ6pmhRFXrk71/M7Qz7FI2NzIv5XWmzYhxkQ58om1adBhx/ PQZmCFJeXkp0pIBSWa3vuca6LOwsvipRoMhXSm9UCYFmYtsny871dIEMWfDaYisV mBSKRw2mZnAo/sjARxjqrPUEAIbzGJL3ePnyqj0P0mLYOqiEi+wxMEUzYpCn9WZc r1I/JWQ1Bri+iQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTtERIZXJuw6JuaSBNYXJxdWVzIChw4omh cCBmb3VuZGF0aW9uKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5mb3VuZGF0aW9uPokC OQQTAQgAIwUCVyc6TgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtX OGUnaPfpn3gP/1V3n9Xt8ha1juDe11jq0y0g1jQr1JMhZOoBOp6ttSpYCe9HCoJw VyvO1iGLex6XHSe8zrWvP38aihFoK7jQBc8xwYht1DcpTM7HFyXJ5/Pch8BNS4ds c8eozvm96pBPPmFDcm+igG6dkO81/9oLqP8+Bagz8G58BktcFhvnjmLrkJftJAJQ 4LyP5KlXgmUIxu9l//Wa8AMkty+feHTIIbrQGDTM44a9N+uHwJ4OQjHNvvOprg4U ZAhehLAzCk+gi68uHfhH0AtKwZ/v/lag7OYle0KZelxFsHnVE+Dhe8HlyKqtCCOC vkWGtz5CBJDO/V/xUQXBSJxJd4Q4w9Gyf0mJ+Ljr8iu1fyaEor68u1ZGkaWbzQSF 8Ycx7o6MWV1fAyFpUNUs3M3vpmJpwrWQdNeCpQaczexnNcrzrYdFDLx8z7MMHEy8 6QSmjmaDSA+VgAHzV3oo4R3Wu3wZKDwm4eFDBj8N5IBxMMfjfinnJb01WkAeRtAq K9KdXeWGs6eO6OBm8OSpao2V/lw3IZIiCdowPaEFzw96DwmES/zTAis74mENrhnb vDrzFVFkNOUdf2Sn9x81FJ7X13TEjENUhJJI87W+Ttk9eKUarkjtKdHfVpEMnO3L g6NJiAvwpcYfarzfmorrwp1pscLZBEFGiAuHVgNzY1YwXMirPVnY7MnziQIcBBIB CAAGBQJXe+cvAAoJEH+zxRJjw92v9lAP/2LhBOb9ztjDKSNJMn1IXJK9ALYor7wG 3JrQvwJGdfKRj8b3p8nlGCtFpo32h/7t/9lNxPJmONJcc76Y+fqviseRNk05iGCO IycL8Q+2bLvzQP1w3exvo2imgJGgtZFZqQR6K/D70TrTwcyzpW6h+lN3ZmZu4Izv 2pdtJMh83PZus0A1cHQUhIjCl46+uNT0BaEAdDpqcC59EWFFwPj+zEhZgTtrAU9c hSXj6s4254WMKa3BIuy90bWqyMuJt8+mLYTfnpNxaYrMX/puC5hs1WQi0BQVXdLR ooSOgYDaip0mXiOyqXHS0V94fuiONqzYYBjQBkpheorVuMDZL49bh2c2VyANxAaf cZSN82isbQG1anl6LJRRiGm6BYC+Ew8OWmVkCEWOK43G6IQ+Nl5Bmv+FyIoBQzaZ 4ioR987nC82cLCbtaMMs9ib5cTZBEIAeDaD0THl08pCLkfR4nPLG/u+dTE5zxSrC P4o7OKLLnYTcOkU9WdhfZV/6a6iBJy3uvuFDoeoJG3Zv037gHFsmd83mo6xm9qls RyY3vOTtxJRxsn6mn4/RetutDxJxvubNZaxxL33coGm8GcMM3BaOdZiRgPOR9E5S MUrlnpaMwWno/mO9ivifW/BFSetfGN37wGeOcoMwwSCfj4OK9WVhfJFqFweL4StM BCQ6OZLcxWb3tDpIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBwcm9qZWN0KSA8aGVy bmFuaUBwZXAtcHJvamVjdC5vcmc+iQI5BBMBCAAjBQJXJzp2AhsjBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+kEng//VY+l7xtGPe9q/FwmZ4Zy APJn/hnwDjGhPeuEgsT4IgX220NB3UEXFAx8tCSuGY85862dC/AGQeGnzoM5u7rl TRFGuv92EtE2n/2Lfbte6yb5MRmzTgdR7cP1aNpvjCN+kEp4FfmHl1XPBFyX6WLE QG+ZnUDFIyHt2I7dehdN8UogJHdIfZ9y3IEhwPqAYq4CRkf7P8Zkk2km2Jh8Xjjg L5dsjCQKuNAnyktDpxUM3N/ifsOfrNulEIKlDA2yW3kcGL3CPj2ugwXgkSykeXaB zVoqbqRcPOO8/J7mVEOoLVjPwYq8f5NGWq2U0rbJnRTHX4benaxw7rCi+6nbAEHT j0zbpx6FH8fezuzx86dWlFngqzQDOkiZWzc7ql/eb7pzHXuQ3QC1D+zzNn9TSTSD AjRFpgIuPWkAb/7/WyRfwqd0XzqinisA78I+E+0MOhjpQab/i9hoQRB2LfGaI+gB taRX3aRotXNT1E5R1fq67r890Sjt3XTzADK9B6RqpMa6T0LDe4zS2CYnDbUBjljs YGR5WZ7K03Qx2p9qfCFBTt2wvy2J0b526b0yCRINc6TWDs/SlRqSs/ATaPSbOKfV UhXI8k0k2SV6FSBEPwIY0cUSRPSoANfv+IXjiW3RBbjNkvpbVtu98CDSbMBefAc3 X8oVtrZ+rigZzd41QAhaOp2JAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8pNw// fQnOl3/RamWxLz3Vs2Righ3M1kZg+NjQ48mIqmSZLzwu9MQTn71nOUdyBnkmEm+b sYviNPQha93wYx4i2ioLKNSXyDa1dBbQloidQm0b3TkeU+5a/CN7r2OauReNvc4V gVupxaeUyEToFW/RnQihbu17zZkwqTmKolQ3hd//1P9nFGccYU/G4DQUonuBzCV6 uOIKZ43KBA8vm4nk8uAW0PNLJHOaVM+vuDgLqx/r703RE1YaebvNC3IuXTfXpQHC GMa/gJQpxGmqLjlKDC63k1lYAk5gApkfj36+RPAiWYpGvo3i0EXTrXlwehqRJoYA 8lNswk7LcvSFXfKugomMtCtH4vJUNL1sgE8tpWhQD73K8q3cHXLPIC3Tk0If+7h3 xdnZArLLQrXEWFsIoRcQDLGVmJhy0Bynl+uNuTwmJRTvMUfXZk0PDu+UdjaK2rDv t38i/K9DkOa5lT39M0yV/RX1W286cjXnKdrHRp4lC9QN9soFuEuCzgjiSKYl+xKa oLGaJwvoxNAmduuLmuVitsriNFf+bi1PSEfDBBHq521Q9D5u3jhGZofGu2HOazCO GhZs041SQ/OP1P8+LjjxwSEpGsQJFdET87oqApCkMy43IEOB0DtOIKSVrdE46QBZ MAGA1KyssNkVozEKH0NU/gGOmjzkt7nS8qWvYIvcKN60Qkhlcm7Dom5pIE1hcnF1 ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXByb2plY3Qu b3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA AAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlNPT3MDYTy D4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSEzFiI5HYI bmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxOVU3iBskn 5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/gnbD7AKJI rpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LYXK3z/7gc NSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAMlK9E/f+3 HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFmkgJYq1pW 9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6jZdOEZPw+ Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3TDdPbxiX nA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRNEaJjLEzb gPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KTHBpxzElR iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBbQ9l5sbcp aCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R360YR0Dl 10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9EafZQlC9 L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tGrs182Fkg Q68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3D/XtemP9 aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+Ic/Dy3GPW T67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgHKRi4blqX GXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhGi7S9VIrZ 9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xtj/HrUbUV yDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5pNsYGk6B 5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsPe4LRmxny dcdD3O0O7RzdwurQV1jjtC9IZXJuYW5pIE1hcnF1ZXMgKHBFcCkgPGhlcm5hbmlA cGVwLXByb2plY3Qub3JnPohGBBMRAgAGBQJV7/dAAAoJEHuDbkH3q5zl2OgAn12X bKVf0usg/exDv8tOxOzPTr8eAJ9b4QFCS/Bayw5zE3Fy650owknfJIkCHAQQAQIA BgUCVfCW0wAKCRA9g02NGPgJNGo+D/0ew5kut7hDw8dADIPpHaaSHfCu+7TskdQx Usbrg/4wvmiQ5lZvFBDtbqvtBHXVQ1Oj2xtPRRdlL5wuiBqf6hpnR8dQclggnALa kVi8D+c38AKQFFBpAPTraa6bCRawSS74+nOyrSpR/hUsYXmDyOvQCBxKpwS7Qi/O b/JpfVZpLwD+297Z+ILNFixbYlYuA7V8z+ErQdkhSpkgtBoeB20gbw/FmqyQKvtM 0ul43mINJpNzYP4yvU4YsDCNClGOYWLLPFLcnvVowmhRmMO7rM0eF6FfhLOGhbb3 1H8akl2Op2C7EiMv2D8DGiZtV5QtVt9r/PCdl9LLEnw1kjULA50yCD0F4eXFLPLU 1S6APqKFtSv9esSINLjo0q1b4S5ekmUEqhBMRHvREPwGmsWjodp7pe1QPNPqb7pr NAOwBxyKveXWIbL0TaYbPhBQ4az7cUsWmlW9Bgn08zu9Jl9t9SdoEp6BV8qk7y6V mimMLYe2pST5dZjweb7+u4Sfnfttxlt6kwu+hyz/c1RX9VdvgkzaJ+8i+pWvHyij miStQTiHtJEcKbzhgHcEDfOkvFMGmNpHlVuB8skUnb9HeGheb6QZ2mRmCwZlKQQI MDYHE6xOIw8RJBHiIhvXOr73mXcORAsBvEAkGKQRldjtuQpb2dWEaL8oz3p4TA6v I/8y4qj7mYkCHAQQAQgABgUCVe/3TgAKCRBLSiQj0EHGPcmQD/9ngwa9R8nsM0CT CMioJEbWJ4INnaDND8uvnPzRT+vyUkTJzM+RCvVOoGgrmCFeqOeCQhdf20ExsANs qtv9XQEyDDI7PvnAnprJLSYozfpYscPe7N2MSwTBiPz70t03L5j6YfJhooCok921 U0+xCNUl3LXzfIkXTxMC0z77VxSqEiHiPgQH4owqnDuEhRPte/ZtzvMgCRIk8L8+ 9UZazl8hF4r9XPP+h8EFVJW0MB2ANICvmHcspiVd6QJdPTYHZIwZ2LMrb5Dt1Qwy NkTDKvoImgR6qiaR06GDyMhis6l8seu6GuAtOZGh2RGsGGPDPozcTi1kdytFmGC0 W2J+bMoYeEMiAH4Ip4o4KvLwvEIhU1RTMWg3Qo172w1Y2FLQSQLar5kVvjHfAdpg AeZMliPl7+ydziDF+EYP2p4d6kw6aPZNoB7uD1mhdgxts0lBuU3iRQwhOQTcrrJj /2DtUPdoFGoR5OTVDrmb1lodw5WWzI8FtTZ7C6ZyGPjj+V7COTSHGP4R7YLXKrPF K+5AjxzozK+cIgvYSZol8ZfAusxzz5mHXeTZqpHkQNdfCCHWCJ7og2W5baprUgkQ n2O9AqEMSLQW9hpMGbzKIVh6ZFl6n2is/dZubS5aCH9+bNJqEi8Vd/pMsW9MMEet eGKc1WoGtDFFDM0YocgvF1CsSfGfMIkCOQQTAQgAIwUCVajOUQIbIwcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpw2sP/3YEftsFv83sPLBclsA5 HFNRr4FsXzbRv9F7grDsqnvecgD8ItwUJ0G/Z/0uqXCPKecnq6mNhRZiX+AtNkGi Mle6xcWI2kacAi/L61GPyXWohsy7d42ej+FK2/lyKScTg979XBAXGJCCfyGoaVU0 Rt9zlHyOOB3091YC4gSYkMJ2i7jsdp7lqqvTwM6oPnEQkS75XliTDKesvYdrK87M TcF5tlBNVq0ycGmpGDOY5+d5HvkaJyhfUeJcknvMPIcObsH674vyhTejXabQg2uU hiWyOFEz4T2Xw72XdvtXhB8eIGNJOrGP8HqG0fhejoyXV7m2n0X9taYB+VqFrRnT 9WeoStaMHzLhEAvOgLIXGe5bDPVkE0fV6SASvClAATtgsrunsYIuhQ5qHmcAxofC r0D4CA4YDhnRQbdbRaEKrHPFKkdtw9W8D2HO8X0xq6FmykYNuKI9k7w5oPgzuGnf tBX/8VpKEaSAOaIX4q4MrelsbyaJ8Ujx4fUFaGHQW2s1rmmJf8BnEEntyDSi3Tq7 JABSeA0O5/JUJS9a4rSMvvssdtYSSAtBD0N8yZTtdjdhaFffPbpv0PKmuNbjX1Fs 0NOJDPWKwrSohXDWqr36ott5ap3/3wf/5upgKNR8AKoqjCF0hmPS2L3S+LNnqlZY 8eomhf9YA1gSN49yR+2hAje7iQI8BBMBCAAmAhsjBwsJCAcDAgEGFQgCCQoLBBYC AwECHgECF4AFAlZfiokCGQEACgkQy1c4ZSdo9+lrTg/9FOyKWzceXttk0a3cnUpo p7AQkQC9FfE9QQzFOW4VHk1ZKTlH7V1QrOrzU5fadd8C71oHbf75fVTlmNtcl9OE 0fnx0T6G+FKvTyJV+W9LIRbsNe8+q7eRRtf/HsjQdblEIqkdUlAhVRgCjBI6K/re MYVoz5FxSGoIMjfxds1K3kQICxS+uu+zRm6ff8VuWHMSESC34IxlIvfBf3vbPYnU Phu4Cn0UTxH3pmHmk+teJ1uFWiX98HAxDpv0ZobKNa9imcSCKhYTqdm89XBXND01 bUd44w3RCmSqgzEQoRi0Jj+ieg4XSn98lOItIBPE2pi92NskdSJr7C5++0fO9xrz URZjqGiEPmiegW+OMvnI6X9O2SBzXYU7GBiqpprWsa/y0WKRJ8O+kEVzGUI1Bnge qvZ52QHGN9v5Wnho0gvAWgiAmDVn6n3yfcnI+SBJHmvy+Im6TI8aNSX4G9xQjVuk M/iWyjsNzAyxjtdkbuOBiKAOADDqTC39HwsGoHXuKIzEZMGTFx7vA1yutogtg8Mf UsqX18Ilt8p6v+dtJJY14MzF9fyVIfVr83Fc0IPuv3f59+7VQPY4AO9rUN+bcjgg dKY9peLGizcT1msWew4byIIjU39EfCx1ojfYkDFmV6fQOMOLWT62RgIiyORRKI0M a2LnrHUqPDU6kWM78skVH+eJAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8koxAA joGdnDNipBywNv9l5QW0pdKesUwSKNA4lxfIuSwDLw7ZTabmMHH6WBZjNmcbw7ro kvuSV5+njrkFG1qTumy+JXtniT7dboEr/lXkibu2EEB8z0QNShMxm3Cf68HRsGQR lAwglnqDnZEOkv5AGWYjxqOfRRCKCIGCGHZkKYVK3K8DU+09ifaAxuR2KLJuPMzY wD8moZkBlyEzT5FhOb6hVCG9uHBeCZcayrMsTFhOKU4Y5GKTNgsE4x6FbZoGCFhT wx1MGkoCvzScPhxmes5kpr/AUZgwaseHWfsaC5XgDqji3Hhu21e6Ez4NkH3Z1CUH LEHzGodxpKJ2EkWVi5ofSzD+19MI3A0qwUgDdGVNMDP0k9SvwMPngA5s6hht7sD+ 6mtSnuHwiNLNZk39Qt7sHUYg4AQRCIwzUrQuJ0PUtFIzox+pMQcVIgVM5rwxnNbq U+iWgSBeadc3PfAr6yF3gJy8U7pN7JSjiEuhNWu83cPm3zuIIVhDwjJKQzs+rNun M4PtithYloEgpoG5tMtbK5qIGIQixddlqXcUQtoiA3gFXO6xQjeqKWJMnxp9q+cB +LhKromZENljj8M0UCtzB4UGu4UIeDGKAPsZUCHjwL3LThyK+9EtLH97oz/Q9IgX H9cEW4Ksisct3MAscra29MPACt2xTRKUiXzNVBlhcAa0Pkhlcm5hbmkgTWFycXVl cyAocEVwIENvdW5jaWwpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJWX4p+AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+lsdw/9Ea0y2n0Indyhw8RaC7u/Lu+OV5a03ATiWuV16vyYFXiJaVTC ildscXCRpSRHrT84zk4eYf6ysRuzlXZUcg009nF6lajuzDm6E66ZJXkoInGpwEcG Mx5odUeSKxcaZ5IQveEWyJahLbHf4FgQts2r8BsChkoSEvhxojBhHQT5FYxdYNcK nrNj63UZw+xwTbg/79PWOjB141OEwNOT4rggXSZ67w8O1JtMtMGYAgI2KiHIxUPr uEudiJI8DvXUakX9LJRTpJnqSacgkC/ahL8m5//7ePriUO2FR6ZeDkGp5z6g59+l iruJhOcmbjpr7wAo6hVzdkpLT8qu4uuoaWM/kRayEKfhlUj0SCcG751ucTE+yH9H MRBDUV/8fhVuoLsEHnq49/J/cVx7qr1y4EfDDaN8zW8ILe4vcZwGgbD0lI5r6tey 2YyvwVEKDEe1vIiarbRsHa+6haX885SAyooIfdqKDcn6NGM12AVAPOIe2+2Q7GZV 6AACD+j7GWX/jiNaV4HwJ2/SsNBFPw2/lDowsHnhFdvwEROynRlGG3FbHMGJ5HrN hQJWWZDPF40hDpuJpQRUuc5uzOzQUptag9m5gfxCQNQXCtlIpIJ3CdlJJjPzndIH ktV6/eo2xiAn24b2yBeiBnKjET6OE5iswAd4DO3BjAKTBYYmqD2OMC+QCzSJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a9w/hAAnMSIrMoIVgk/o7Xlyh/9TR3WTRsm cxM3Vmz+KI4hzCXde9JK8a+vrZMhSH/ZBBanFPQolu7zRbj7+MeY/g4cJZDsuHBM 1+vhwjxwFPWXRBWdNZFJIzz14PF1TVGbsaQw2r9q6cg6u64pZYA3G/scfcRxPMsb QnVBz0Lg7f2Jrav3TkuwvjnKpnZc0iZ6QuIyAwUdth8TY7y3hXY56VwT1rrtOHXX E0RKaDfCoyep8rRG/+qhiZT1WGzq7LDAIeCR5DdleCaT+bXMsK1N6Xk2il6vXjed vGOtl12I9IgqC30tqqJMpWrRb1KFX60l6oCOYqrAqysajf1BFJeDmiZgpxLcePLD 9XrzNHqKrK7ZRVGmc7aKSvxIyWRrorYDh42MEtw8b/k6ZkXdH2yk+PZUPDMNXGVk 6o4kNhV0g0xL8lIqCk+Oo823F0jTYcasf3vRe1OxsKPJuH+INOJMAkmYUvi/QOKz /pycJLPadN/PVuLD/yTkdfnPP9rcj73uQpjgwTfG8N7XVgmYrbYmT21PWU4cHprU AVexEBMaQtaz7k37rgfqjZyIfGFzrBAVBRmnDm/+KZid4SnHvIMQqC5UaZFImxfY ZcgSY5sqLjNJmiaTKpKBcE/vss7hyZvsmwvlxT652CNvdtYSehDO/F9LZBlIZojv 5RO7TalIRpTCERS5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ1qHy2DtT+0JUHiEM bY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JCxXGGISJMI0tS+1b6 1NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLlJxkP30s8tUeGMRzc WSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFhr8jCtlg4ug0HrySl LqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm6ckap6FBziAwcfnT fnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5wGntS6cIMJYbbKKGw dsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1Z49x/tTKykUM6/mh eqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQgL/UVZDVTcuP0MuG9 tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3GcNGk6sX+eeEMkfZ 0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQHEqPfFcYdY3QCay5 Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0NTGRC6yMFAGSshsx3 z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4ZSdo9+kphw//Sw7J i9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt5G5dmKwmaYrPGS3H r2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyMzo2NJGz6btuFey6Z iMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091FVj6rFeda/e7g3xK2 NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6aTjZWPSmTVTO21t8 s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0FgM/nTj04cBNW91q8 tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7rWJdxXjAh6Y3FiVc 5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdpXZ7WBaPD0R4/QcXS 9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvtohCGJW0Ksc8GjTxWt mgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWmxQqAK92/Iwt/NBAL Q2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu8iYrvghKyC1RKKPP jqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DNrbg -----END PGP PUBLIC KEY BLOCK----- --------------F5368C44A5AAF4B121B17703-- --OKk2XrdI3lowakdIxwSlZVlze2zZETUHK-- --iNP3JyEq9UoV9si7yv8OnRL3bNO9vH4Fo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlqQf9cACgkQy1c4ZSdo 9+nE+A/+NavVSTNSsLH/hT8d25V+JB21sgqyJ2VBSjvzd3uO7b5JrqTRK+AGuq9q 5LMmJByQF7mtywAlMv+zimvztil5Aphrq7rpJhFmrBgCnJxvzN+xDoI/9iTKrWJp IvIUnhsZFKctBn1/bHMtqtx4NLtcw9IUiZ14A8+FUhRQCslxgwOfyoL3tImVudRy hz9qLcz9GNNCC9gOlpV7SFsOIfw4PMVACzSDkuXtRHxZAJRg+0kUaYFGJP6didZ6 Lxd+GWNMxpPsu9Yym1c+JLq8h/JxAgqeK3TGhlM1YPEP44dCMr1cSiEfW2IERudt rFVuYfyjwkspMH1w/EUxwFLlRlZcQVGaxrFSaQv9aJWAULtICcdy1mP40Z/qcGjz 6/mRUfz0wwdiPZsCii/BA9pACK821jSVTEZU99KwP6tY303XIlNvfaChlLMIKP/8 pZDo38UEBUq2a1sp8R/LykKjmbokJF12pHf6hdAfOQt3H+Fak0oUKptkECNsaUUQ 1fCWGdLQjSKgIu9TzG+qpkGhdLzNH/KonRgG/aMklptcGe4flhmwSjAOQTYhZEyg hC+ysqmu42ybmFV8Un15FGXGN+MLORTLP7URjemO5/0Qe4DAG/qtbV4n6pMMIhOg C5zGmtNxi9QKgrycE16f8VLjeM65BY6HtRyCHsB5lGz5qyX8+AY= =H0eY -----END PGP SIGNATURE----- --iNP3JyEq9UoV9si7yv8OnRL3bNO9vH4Fo-- From nobody Fri Feb 23 13:14:39 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18816124BAC for ; Fri, 23 Feb 2018 13:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 XZE0RA84QXXu for ; Fri, 23 Feb 2018 13:14:35 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5541241F5 for ; Fri, 23 Feb 2018 13:14:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id DD57B171C071 for ; Fri, 23 Feb 2018 22:14:32 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWnquINHEFDd for ; Fri, 23 Feb 2018 22:14:30 +0100 (CET) Received: from localhost (85-195-255-208.fiber7.init7.net [85.195.255.208]) by dragon.pibit.ch (Postfix) with ESMTPSA id 5FB0F171C05F for ; Fri, 23 Feb 2018 22:14:30 +0100 (CET) Date: Fri, 23 Feb 2018 22:14:30 +0100 From: Volker Birk To: saag@ietf.org Message-ID: <20180223211430.o5anpinqixkrgoss@pep-project.org> Mail-Followup-To: saag@ietf.org References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> <10478.1519411521@obiwan.sandelman.ca> <20180223185748.75pdjo5yisoe24yc@mx4.yitter.info> <7f0586de-6206-68e4-3bd4-880cbab9ed2d@pep.foundation> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dylhevfrdctpkau6" Content-Disposition: inline In-Reply-To: <7f0586de-6206-68e4-3bd4-880cbab9ed2d@pep.foundation> X-PGP-Key: http://fdik.org/vb.key Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 21:14:37 -0000 --dylhevfrdctpkau6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 23, 2018 at 09:55:51PM +0100, Hern=C3=A2ni Marques (p=E2=89=A1p= foundation) wrote: > However, Trustwords -- as stated in the document -- can also be used for > any other mapping where fingerprints play a role. BTW: I'm using them for SSH already. Yours, VB. --=20 Volker Birk, p=E2=89=A1p project mailto:vb@pep-project.org https://prettyeasyprivacy.com https://pep.foundation --dylhevfrdctpkau6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE20cTGDZgoSq6+ncU6+kNRBRvYvQFAlqQhDYACgkQ6+kNRBRv YvTWOA/9H6b7770Fp7owX8uHhfsR16Xvpczu3sCvlqkPd2Z1BnD+tj96Cq/4Aymj v4FgPgFfJ0i3mARrJUHvJ2JyVTpC+RlftlJq2VkruLj9mQu2eywHk94f2Bg9gDP9 ugVk1nS+57cJV8v/LDDHsgB8LyhSqlyjxuadNw+822wTILhSxkNLi2/+kgeSkoym 9AmoQl+KNImKB5MVmdbytqlH1fYPeMkhqevEdfdefSdMdanDXswxnVf9YahRsVow QWMsm7iXjF4L+FwmjX41B96XgnYEBCE+L33zX5fe2sGrT0k469pEaKYMCLhBW/g+ D9sKJfVZ24xJir5qUodMlA1zFuCpYMQvnDJlr1URixM5CVR3JYSyIaXOUB76PAWv AsSBja68k+JSY7wSVWC+GFMTpYlkNGQB8C/JFccs0i6aWUI39uuANIOVm3l1Dj7a CRJ3cFytA5Vtcz32SJ1jHLsZV/N2GFsJ+wfzFl6//GtM4ZJLdV/lz9gZLIKHfEoe WLr5irftm+ALRJ6Mwrx9iZZV6K80/b68YJHDU2MifPqLlUZ+40Ha1VUReuFhKJTC bzPnMB1B65W8Yb1/NXzlW4d5bvAccpuvaudDQH7AP5aKYo+wFHRcB5/NeF9Diyuz SYyQJxGW15ZYXYWG+Kc1veGFQ9cKUy+Jx9drmeENiBqMTskhs5M= =51Qa -----END PGP SIGNATURE----- --dylhevfrdctpkau6-- From nobody Fri Feb 23 14:38:58 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DB21270AC for ; Fri, 23 Feb 2018 14:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 S4N_1kLSFOgt for ; Fri, 23 Feb 2018 14:38:54 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246A812708C for ; Fri, 23 Feb 2018 14:38:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id EDDD7171C071; Fri, 23 Feb 2018 23:38:50 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RsuJxwHoyUH; Fri, 23 Feb 2018 23:38:48 +0100 (CET) Received: from [192.168.43.106] (171.225.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch [178.197.225.171]) by dragon.pibit.ch (Postfix) with ESMTPSA id D9F7A171C05F; Fri, 23 Feb 2018 23:38:47 +0100 (CET) To: saag@ietf.org References: Cc: "Neal H. Walfield" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= Openpgp: id=31733E0C598D3A1CF70955D6CB5738652768F7E9 Message-ID: <8f1b37c0-c71c-a979-7e3b-68e4ce41a769@pep.foundation> Date: Fri, 23 Feb 2018 23:38:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bcXUUgXyBxMypY1vtyojywUt7yZ47nI5b" Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 22:38:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bcXUUgXyBxMypY1vtyojywUt7yZ47nI5b Content-Type: multipart/mixed; boundary="K2FIu6hk4MEqTAIUoiIOJ1OQqTLD3mev2"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= To: saag@ietf.org Cc: "Neal H. Walfield" Message-ID: <8f1b37c0-c71c-a979-7e3b-68e4ce41a769@pep.foundation> Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) References: In-Reply-To: --K2FIu6hk4MEqTAIUoiIOJ1OQqTLD3mev2 Content-Type: multipart/mixed; boundary="------------1A0D70B0C8D6EF0B976918E1" Content-Language: de-CH This is a multi-part message in MIME format. --------------1A0D70B0C8D6EF0B976918E1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23.02.2018 11:42, Bernie Hoeneisen wrote: > Please be informed that another I-D of the pEp (Pretty Easy Privacy) > series has just been published. You can find it on: >=20 > =C2=A0 https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ >=20 > Abstract: >=20 > =C2=A0 =C2=A0In public-key cryptography comparing the public keys' fing= erprints of > =C2=A0 =C2=A0the communication partners involved is vital to ensure tha= t there is > =C2=A0 =C2=A0no man-in-the-middle (MITM) attack on the communication ch= annel. > =C2=A0 =C2=A0Fingerprints normally consist of a chain of hexadecimal ch= ars. > =C2=A0 =C2=A0However, comparing hexadecimal strings is often impractica= l for > =C2=A0 =C2=A0regular users and prone to misunderstandings. >=20 > =C2=A0 =C2=A0To mitigate these challenges, this memo proposes the compa= rision of > =C2=A0 =C2=A0trustwords as opposed to hexadecimal strings.=C2=A0 Trustw= ords are common > =C2=A0 =C2=A0words in a natural language (e.g., English) to which the h= exidecimal > =C2=A0 =C2=A0strings are mapped to.=C2=A0 This makes the verification p= rocess more > =C2=A0 =C2=A0natural. >=20 > Anyways, we are looking forward to your feedback! Neal Walfield (CC), working at p=E2=89=A1p foundation on Sequoia (a new O= penPGP implementation in Rust: https://www.sequoia-pgp.org/), suggested to take this two documents into consideration when discussing such mappings: https://www.eff.org/de/deeplinks/2016/07/new-wordlists-random-passphrases= https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf Thanks, Neal! --=20 p=E2=89=A1p foundation: https://pep.foundation/ --------------1A0D70B0C8D6EF0B976918E1 Content-Type: application/pgp-keys; name="0xCB5738652768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xCB5738652768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjkEEwEIACMFAlcnOjUCGyMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDLVzhlJ2j36SSQEAC7L0ZgFNXZAsXUzDIj7ZcyG41jcIaF oBz+VyIz/72zsr7tR469bq9QulnEdhr5Zxa+sZauT+tktmehpQpkwAZRXb4jHawS MVGwzssKehUe+sN9rrkIKvFbKMHcL/ZUiaFKNL0dX/tbtA/lZGwMSGlE9x1BWPKX JrqiKUpvk278jFwkOfx+mzVSuuIcIn2o25BM6n4wxQnDizcES2Z9nXyYzSBagvW0 v2LsOEatYgCFoTxuO37uPHXL3NlhipRx5dfIxKjX5zr2DOxKcS7SPio9cGJ8Z5gB jfC3ByoZfQVmrR0lfIxZVtFTzR8my+fOLDhL5U+3RVbGHHHjzJZY03a8RUpcWsMr +lsogSH4h5z8QgkwfhTyBAUIcewHU5128dRG8m+wfTTHnQFCpmd0Ql3beRbAhN/e xQx5aJq81rPD7dunQtKB7iyiDpHjLWJ22aBr75GjSfF05Gr4LgLMFkATzrpnlXyR uLtZ0TTURWw+pximLJu/Smn5CKUClJayGOgp8a6bmNlxn6li6SZVoyu/S9RCUWTB z2dsv+iDjk/La7gcLxwrtkf2wFxvauaax5BjXoEnOAsD12wF3Snr6ymARh65rZ+C /HaiRpUXoUFIWUh0gRnJHa+EOxXq2wKBJul5toTlOEiqK93vVwKLlPgjiEY5NHEU 7zpE7skkXYqKhIkCPAQTAQgAJgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA BQJXJzpdAhkBAAoJEMtXOGUnaPfpktIP/iTLClFO8y+KN00z7cHxbistBKjkFlS+ Q4RzNmXQXgXMaB9pMvIbCP6Fm11q13GGT2MLm5gpoIBH50/fCXxWPGaeMRyKvv3p PDbSwm7J7hDP5H2yCGclkzs0NntiZXbOmLhFdZjsIhi2GnNSrUve6MOUM18p0ph3 f0+Ia3Ki3HaURLD4sGUJ12ig8tLI82nt+NaxEKCaD7b7KtV2XtMQ7RAVwax8to2m PBWzZReX4nMmqX8LNXhn1DFkCSGCl45umK7i39Em4+OYpLyWy3vMmKuGXA6uVenl WQbKuaw+Rer+MUOTM2sABfm5ffiNMGBO94JEGvgwSVUCmrqyBsZ846q+FTlJnapY /D63bIeINuX20TYxpzZSKh0U9sVKU6cd3koeH6CFYPLEICQBzDFZ7GTg9MJbAbGp y/P3klwdfHo8AcM6QIH7MIdfrkk5WljF1vz3FvWcGmoqmGRdrHt/JBsDw94p/d6G n/HWAX3gJvrF6+BTDUZ6pmhRFXrk71/M7Qz7FI2NzIv5XWmzYhxkQ58om1adBhx/ PQZmCFJeXkp0pIBSWa3vuca6LOwsvipRoMhXSm9UCYFmYtsny871dIEMWfDaYisV mBSKRw2mZnAo/sjARxjqrPUEAIbzGJL3ePnyqj0P0mLYOqiEi+wxMEUzYpCn9WZc r1I/JWQ1Bri+iQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTtERIZXJuw6JuaSBNYXJxdWVzIChw4omh cCBmb3VuZGF0aW9uKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5mb3VuZGF0aW9uPokC OQQTAQgAIwUCVyc6TgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtX OGUnaPfpn3gP/1V3n9Xt8ha1juDe11jq0y0g1jQr1JMhZOoBOp6ttSpYCe9HCoJw VyvO1iGLex6XHSe8zrWvP38aihFoK7jQBc8xwYht1DcpTM7HFyXJ5/Pch8BNS4ds c8eozvm96pBPPmFDcm+igG6dkO81/9oLqP8+Bagz8G58BktcFhvnjmLrkJftJAJQ 4LyP5KlXgmUIxu9l//Wa8AMkty+feHTIIbrQGDTM44a9N+uHwJ4OQjHNvvOprg4U ZAhehLAzCk+gi68uHfhH0AtKwZ/v/lag7OYle0KZelxFsHnVE+Dhe8HlyKqtCCOC vkWGtz5CBJDO/V/xUQXBSJxJd4Q4w9Gyf0mJ+Ljr8iu1fyaEor68u1ZGkaWbzQSF 8Ycx7o6MWV1fAyFpUNUs3M3vpmJpwrWQdNeCpQaczexnNcrzrYdFDLx8z7MMHEy8 6QSmjmaDSA+VgAHzV3oo4R3Wu3wZKDwm4eFDBj8N5IBxMMfjfinnJb01WkAeRtAq K9KdXeWGs6eO6OBm8OSpao2V/lw3IZIiCdowPaEFzw96DwmES/zTAis74mENrhnb vDrzFVFkNOUdf2Sn9x81FJ7X13TEjENUhJJI87W+Ttk9eKUarkjtKdHfVpEMnO3L g6NJiAvwpcYfarzfmorrwp1pscLZBEFGiAuHVgNzY1YwXMirPVnY7MnziQIcBBIB CAAGBQJXe+cvAAoJEH+zxRJjw92v9lAP/2LhBOb9ztjDKSNJMn1IXJK9ALYor7wG 3JrQvwJGdfKRj8b3p8nlGCtFpo32h/7t/9lNxPJmONJcc76Y+fqviseRNk05iGCO IycL8Q+2bLvzQP1w3exvo2imgJGgtZFZqQR6K/D70TrTwcyzpW6h+lN3ZmZu4Izv 2pdtJMh83PZus0A1cHQUhIjCl46+uNT0BaEAdDpqcC59EWFFwPj+zEhZgTtrAU9c hSXj6s4254WMKa3BIuy90bWqyMuJt8+mLYTfnpNxaYrMX/puC5hs1WQi0BQVXdLR ooSOgYDaip0mXiOyqXHS0V94fuiONqzYYBjQBkpheorVuMDZL49bh2c2VyANxAaf cZSN82isbQG1anl6LJRRiGm6BYC+Ew8OWmVkCEWOK43G6IQ+Nl5Bmv+FyIoBQzaZ 4ioR987nC82cLCbtaMMs9ib5cTZBEIAeDaD0THl08pCLkfR4nPLG/u+dTE5zxSrC P4o7OKLLnYTcOkU9WdhfZV/6a6iBJy3uvuFDoeoJG3Zv037gHFsmd83mo6xm9qls RyY3vOTtxJRxsn6mn4/RetutDxJxvubNZaxxL33coGm8GcMM3BaOdZiRgPOR9E5S MUrlnpaMwWno/mO9ivifW/BFSetfGN37wGeOcoMwwSCfj4OK9WVhfJFqFweL4StM BCQ6OZLcxWb3tDpIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBwcm9qZWN0KSA8aGVy bmFuaUBwZXAtcHJvamVjdC5vcmc+iQI5BBMBCAAjBQJXJzp2AhsjBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+kEng//VY+l7xtGPe9q/FwmZ4Zy APJn/hnwDjGhPeuEgsT4IgX220NB3UEXFAx8tCSuGY85862dC/AGQeGnzoM5u7rl TRFGuv92EtE2n/2Lfbte6yb5MRmzTgdR7cP1aNpvjCN+kEp4FfmHl1XPBFyX6WLE QG+ZnUDFIyHt2I7dehdN8UogJHdIfZ9y3IEhwPqAYq4CRkf7P8Zkk2km2Jh8Xjjg L5dsjCQKuNAnyktDpxUM3N/ifsOfrNulEIKlDA2yW3kcGL3CPj2ugwXgkSykeXaB zVoqbqRcPOO8/J7mVEOoLVjPwYq8f5NGWq2U0rbJnRTHX4benaxw7rCi+6nbAEHT j0zbpx6FH8fezuzx86dWlFngqzQDOkiZWzc7ql/eb7pzHXuQ3QC1D+zzNn9TSTSD AjRFpgIuPWkAb/7/WyRfwqd0XzqinisA78I+E+0MOhjpQab/i9hoQRB2LfGaI+gB taRX3aRotXNT1E5R1fq67r890Sjt3XTzADK9B6RqpMa6T0LDe4zS2CYnDbUBjljs YGR5WZ7K03Qx2p9qfCFBTt2wvy2J0b526b0yCRINc6TWDs/SlRqSs/ATaPSbOKfV UhXI8k0k2SV6FSBEPwIY0cUSRPSoANfv+IXjiW3RBbjNkvpbVtu98CDSbMBefAc3 X8oVtrZ+rigZzd41QAhaOp2JAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8pNw// fQnOl3/RamWxLz3Vs2Righ3M1kZg+NjQ48mIqmSZLzwu9MQTn71nOUdyBnkmEm+b sYviNPQha93wYx4i2ioLKNSXyDa1dBbQloidQm0b3TkeU+5a/CN7r2OauReNvc4V gVupxaeUyEToFW/RnQihbu17zZkwqTmKolQ3hd//1P9nFGccYU/G4DQUonuBzCV6 uOIKZ43KBA8vm4nk8uAW0PNLJHOaVM+vuDgLqx/r703RE1YaebvNC3IuXTfXpQHC GMa/gJQpxGmqLjlKDC63k1lYAk5gApkfj36+RPAiWYpGvo3i0EXTrXlwehqRJoYA 8lNswk7LcvSFXfKugomMtCtH4vJUNL1sgE8tpWhQD73K8q3cHXLPIC3Tk0If+7h3 xdnZArLLQrXEWFsIoRcQDLGVmJhy0Bynl+uNuTwmJRTvMUfXZk0PDu+UdjaK2rDv t38i/K9DkOa5lT39M0yV/RX1W286cjXnKdrHRp4lC9QN9soFuEuCzgjiSKYl+xKa oLGaJwvoxNAmduuLmuVitsriNFf+bi1PSEfDBBHq521Q9D5u3jhGZofGu2HOazCO GhZs041SQ/OP1P8+LjjxwSEpGsQJFdET87oqApCkMy43IEOB0DtOIKSVrdE46QBZ MAGA1KyssNkVozEKH0NU/gGOmjzkt7nS8qWvYIvcKN60Qkhlcm7Dom5pIE1hcnF1 ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXByb2plY3Qu b3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA AAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlNPT3MDYTy D4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSEzFiI5HYI bmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxOVU3iBskn 5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/gnbD7AKJI rpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LYXK3z/7gc NSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAMlK9E/f+3 HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFmkgJYq1pW 9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6jZdOEZPw+ Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3TDdPbxiX nA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRNEaJjLEzb gPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KTHBpxzElR iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBbQ9l5sbcp aCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R360YR0Dl 10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9EafZQlC9 L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tGrs182Fkg Q68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3D/XtemP9 aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+Ic/Dy3GPW T67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgHKRi4blqX GXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhGi7S9VIrZ 9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xtj/HrUbUV yDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5pNsYGk6B 5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsPe4LRmxny dcdD3O0O7RzdwurQV1jjtC9IZXJuYW5pIE1hcnF1ZXMgKHBFcCkgPGhlcm5hbmlA cGVwLXByb2plY3Qub3JnPohGBBMRAgAGBQJV7/dAAAoJEHuDbkH3q5zl2OgAn12X bKVf0usg/exDv8tOxOzPTr8eAJ9b4QFCS/Bayw5zE3Fy650owknfJIkCHAQQAQIA BgUCVfCW0wAKCRA9g02NGPgJNGo+D/0ew5kut7hDw8dADIPpHaaSHfCu+7TskdQx Usbrg/4wvmiQ5lZvFBDtbqvtBHXVQ1Oj2xtPRRdlL5wuiBqf6hpnR8dQclggnALa kVi8D+c38AKQFFBpAPTraa6bCRawSS74+nOyrSpR/hUsYXmDyOvQCBxKpwS7Qi/O b/JpfVZpLwD+297Z+ILNFixbYlYuA7V8z+ErQdkhSpkgtBoeB20gbw/FmqyQKvtM 0ul43mINJpNzYP4yvU4YsDCNClGOYWLLPFLcnvVowmhRmMO7rM0eF6FfhLOGhbb3 1H8akl2Op2C7EiMv2D8DGiZtV5QtVt9r/PCdl9LLEnw1kjULA50yCD0F4eXFLPLU 1S6APqKFtSv9esSINLjo0q1b4S5ekmUEqhBMRHvREPwGmsWjodp7pe1QPNPqb7pr NAOwBxyKveXWIbL0TaYbPhBQ4az7cUsWmlW9Bgn08zu9Jl9t9SdoEp6BV8qk7y6V mimMLYe2pST5dZjweb7+u4Sfnfttxlt6kwu+hyz/c1RX9VdvgkzaJ+8i+pWvHyij miStQTiHtJEcKbzhgHcEDfOkvFMGmNpHlVuB8skUnb9HeGheb6QZ2mRmCwZlKQQI MDYHE6xOIw8RJBHiIhvXOr73mXcORAsBvEAkGKQRldjtuQpb2dWEaL8oz3p4TA6v I/8y4qj7mYkCHAQQAQgABgUCVe/3TgAKCRBLSiQj0EHGPcmQD/9ngwa9R8nsM0CT CMioJEbWJ4INnaDND8uvnPzRT+vyUkTJzM+RCvVOoGgrmCFeqOeCQhdf20ExsANs qtv9XQEyDDI7PvnAnprJLSYozfpYscPe7N2MSwTBiPz70t03L5j6YfJhooCok921 U0+xCNUl3LXzfIkXTxMC0z77VxSqEiHiPgQH4owqnDuEhRPte/ZtzvMgCRIk8L8+ 9UZazl8hF4r9XPP+h8EFVJW0MB2ANICvmHcspiVd6QJdPTYHZIwZ2LMrb5Dt1Qwy NkTDKvoImgR6qiaR06GDyMhis6l8seu6GuAtOZGh2RGsGGPDPozcTi1kdytFmGC0 W2J+bMoYeEMiAH4Ip4o4KvLwvEIhU1RTMWg3Qo172w1Y2FLQSQLar5kVvjHfAdpg AeZMliPl7+ydziDF+EYP2p4d6kw6aPZNoB7uD1mhdgxts0lBuU3iRQwhOQTcrrJj /2DtUPdoFGoR5OTVDrmb1lodw5WWzI8FtTZ7C6ZyGPjj+V7COTSHGP4R7YLXKrPF K+5AjxzozK+cIgvYSZol8ZfAusxzz5mHXeTZqpHkQNdfCCHWCJ7og2W5baprUgkQ n2O9AqEMSLQW9hpMGbzKIVh6ZFl6n2is/dZubS5aCH9+bNJqEi8Vd/pMsW9MMEet eGKc1WoGtDFFDM0YocgvF1CsSfGfMIkCOQQTAQgAIwUCVajOUQIbIwcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpw2sP/3YEftsFv83sPLBclsA5 HFNRr4FsXzbRv9F7grDsqnvecgD8ItwUJ0G/Z/0uqXCPKecnq6mNhRZiX+AtNkGi Mle6xcWI2kacAi/L61GPyXWohsy7d42ej+FK2/lyKScTg979XBAXGJCCfyGoaVU0 Rt9zlHyOOB3091YC4gSYkMJ2i7jsdp7lqqvTwM6oPnEQkS75XliTDKesvYdrK87M TcF5tlBNVq0ycGmpGDOY5+d5HvkaJyhfUeJcknvMPIcObsH674vyhTejXabQg2uU hiWyOFEz4T2Xw72XdvtXhB8eIGNJOrGP8HqG0fhejoyXV7m2n0X9taYB+VqFrRnT 9WeoStaMHzLhEAvOgLIXGe5bDPVkE0fV6SASvClAATtgsrunsYIuhQ5qHmcAxofC r0D4CA4YDhnRQbdbRaEKrHPFKkdtw9W8D2HO8X0xq6FmykYNuKI9k7w5oPgzuGnf tBX/8VpKEaSAOaIX4q4MrelsbyaJ8Ujx4fUFaGHQW2s1rmmJf8BnEEntyDSi3Tq7 JABSeA0O5/JUJS9a4rSMvvssdtYSSAtBD0N8yZTtdjdhaFffPbpv0PKmuNbjX1Fs 0NOJDPWKwrSohXDWqr36ott5ap3/3wf/5upgKNR8AKoqjCF0hmPS2L3S+LNnqlZY 8eomhf9YA1gSN49yR+2hAje7iQI8BBMBCAAmAhsjBwsJCAcDAgEGFQgCCQoLBBYC AwECHgECF4AFAlZfiokCGQEACgkQy1c4ZSdo9+lrTg/9FOyKWzceXttk0a3cnUpo p7AQkQC9FfE9QQzFOW4VHk1ZKTlH7V1QrOrzU5fadd8C71oHbf75fVTlmNtcl9OE 0fnx0T6G+FKvTyJV+W9LIRbsNe8+q7eRRtf/HsjQdblEIqkdUlAhVRgCjBI6K/re MYVoz5FxSGoIMjfxds1K3kQICxS+uu+zRm6ff8VuWHMSESC34IxlIvfBf3vbPYnU Phu4Cn0UTxH3pmHmk+teJ1uFWiX98HAxDpv0ZobKNa9imcSCKhYTqdm89XBXND01 bUd44w3RCmSqgzEQoRi0Jj+ieg4XSn98lOItIBPE2pi92NskdSJr7C5++0fO9xrz URZjqGiEPmiegW+OMvnI6X9O2SBzXYU7GBiqpprWsa/y0WKRJ8O+kEVzGUI1Bnge qvZ52QHGN9v5Wnho0gvAWgiAmDVn6n3yfcnI+SBJHmvy+Im6TI8aNSX4G9xQjVuk M/iWyjsNzAyxjtdkbuOBiKAOADDqTC39HwsGoHXuKIzEZMGTFx7vA1yutogtg8Mf UsqX18Ilt8p6v+dtJJY14MzF9fyVIfVr83Fc0IPuv3f59+7VQPY4AO9rUN+bcjgg dKY9peLGizcT1msWew4byIIjU39EfCx1ojfYkDFmV6fQOMOLWT62RgIiyORRKI0M a2LnrHUqPDU6kWM78skVH+eJAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8koxAA joGdnDNipBywNv9l5QW0pdKesUwSKNA4lxfIuSwDLw7ZTabmMHH6WBZjNmcbw7ro kvuSV5+njrkFG1qTumy+JXtniT7dboEr/lXkibu2EEB8z0QNShMxm3Cf68HRsGQR lAwglnqDnZEOkv5AGWYjxqOfRRCKCIGCGHZkKYVK3K8DU+09ifaAxuR2KLJuPMzY wD8moZkBlyEzT5FhOb6hVCG9uHBeCZcayrMsTFhOKU4Y5GKTNgsE4x6FbZoGCFhT wx1MGkoCvzScPhxmes5kpr/AUZgwaseHWfsaC5XgDqji3Hhu21e6Ez4NkH3Z1CUH LEHzGodxpKJ2EkWVi5ofSzD+19MI3A0qwUgDdGVNMDP0k9SvwMPngA5s6hht7sD+ 6mtSnuHwiNLNZk39Qt7sHUYg4AQRCIwzUrQuJ0PUtFIzox+pMQcVIgVM5rwxnNbq U+iWgSBeadc3PfAr6yF3gJy8U7pN7JSjiEuhNWu83cPm3zuIIVhDwjJKQzs+rNun M4PtithYloEgpoG5tMtbK5qIGIQixddlqXcUQtoiA3gFXO6xQjeqKWJMnxp9q+cB +LhKromZENljj8M0UCtzB4UGu4UIeDGKAPsZUCHjwL3LThyK+9EtLH97oz/Q9IgX H9cEW4Ksisct3MAscra29MPACt2xTRKUiXzNVBlhcAa0Pkhlcm5hbmkgTWFycXVl cyAocEVwIENvdW5jaWwpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJWX4p+AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+lsdw/9Ea0y2n0Indyhw8RaC7u/Lu+OV5a03ATiWuV16vyYFXiJaVTC ildscXCRpSRHrT84zk4eYf6ysRuzlXZUcg009nF6lajuzDm6E66ZJXkoInGpwEcG Mx5odUeSKxcaZ5IQveEWyJahLbHf4FgQts2r8BsChkoSEvhxojBhHQT5FYxdYNcK nrNj63UZw+xwTbg/79PWOjB141OEwNOT4rggXSZ67w8O1JtMtMGYAgI2KiHIxUPr uEudiJI8DvXUakX9LJRTpJnqSacgkC/ahL8m5//7ePriUO2FR6ZeDkGp5z6g59+l iruJhOcmbjpr7wAo6hVzdkpLT8qu4uuoaWM/kRayEKfhlUj0SCcG751ucTE+yH9H MRBDUV/8fhVuoLsEHnq49/J/cVx7qr1y4EfDDaN8zW8ILe4vcZwGgbD0lI5r6tey 2YyvwVEKDEe1vIiarbRsHa+6haX885SAyooIfdqKDcn6NGM12AVAPOIe2+2Q7GZV 6AACD+j7GWX/jiNaV4HwJ2/SsNBFPw2/lDowsHnhFdvwEROynRlGG3FbHMGJ5HrN hQJWWZDPF40hDpuJpQRUuc5uzOzQUptag9m5gfxCQNQXCtlIpIJ3CdlJJjPzndIH ktV6/eo2xiAn24b2yBeiBnKjET6OE5iswAd4DO3BjAKTBYYmqD2OMC+QCzSJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a9w/hAAnMSIrMoIVgk/o7Xlyh/9TR3WTRsm cxM3Vmz+KI4hzCXde9JK8a+vrZMhSH/ZBBanFPQolu7zRbj7+MeY/g4cJZDsuHBM 1+vhwjxwFPWXRBWdNZFJIzz14PF1TVGbsaQw2r9q6cg6u64pZYA3G/scfcRxPMsb QnVBz0Lg7f2Jrav3TkuwvjnKpnZc0iZ6QuIyAwUdth8TY7y3hXY56VwT1rrtOHXX E0RKaDfCoyep8rRG/+qhiZT1WGzq7LDAIeCR5DdleCaT+bXMsK1N6Xk2il6vXjed vGOtl12I9IgqC30tqqJMpWrRb1KFX60l6oCOYqrAqysajf1BFJeDmiZgpxLcePLD 9XrzNHqKrK7ZRVGmc7aKSvxIyWRrorYDh42MEtw8b/k6ZkXdH2yk+PZUPDMNXGVk 6o4kNhV0g0xL8lIqCk+Oo823F0jTYcasf3vRe1OxsKPJuH+INOJMAkmYUvi/QOKz /pycJLPadN/PVuLD/yTkdfnPP9rcj73uQpjgwTfG8N7XVgmYrbYmT21PWU4cHprU AVexEBMaQtaz7k37rgfqjZyIfGFzrBAVBRmnDm/+KZid4SnHvIMQqC5UaZFImxfY ZcgSY5sqLjNJmiaTKpKBcE/vss7hyZvsmwvlxT652CNvdtYSehDO/F9LZBlIZojv 5RO7TalIRpTCERS5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ1qHy2DtT+0JUHiEM bY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JCxXGGISJMI0tS+1b6 1NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLlJxkP30s8tUeGMRzc WSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFhr8jCtlg4ug0HrySl LqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm6ckap6FBziAwcfnT fnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5wGntS6cIMJYbbKKGw dsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1Z49x/tTKykUM6/mh eqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQgL/UVZDVTcuP0MuG9 tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3GcNGk6sX+eeEMkfZ 0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQHEqPfFcYdY3QCay5 Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0NTGRC6yMFAGSshsx3 z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4ZSdo9+kphw//Sw7J i9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt5G5dmKwmaYrPGS3H r2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyMzo2NJGz6btuFey6Z iMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091FVj6rFeda/e7g3xK2 NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6aTjZWPSmTVTO21t8 s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0FgM/nTj04cBNW91q8 tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7rWJdxXjAh6Y3FiVc 5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdpXZ7WBaPD0R4/QcXS 9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvtohCGJW0Ksc8GjTxWt mgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWmxQqAK92/Iwt/NBAL Q2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu8iYrvghKyC1RKKPP jqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DNrbg -----END PGP PUBLIC KEY BLOCK----- --------------1A0D70B0C8D6EF0B976918E1-- --K2FIu6hk4MEqTAIUoiIOJ1OQqTLD3mev2-- --bcXUUgXyBxMypY1vtyojywUt7yZ47nI5b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlqQl/cACgkQy1c4ZSdo 9+laVA//Tl9o2jtfSS364v9VHfaKm0QuIJk8oImTXGX60qdEZdvq6LiLbv8Bg24R Obe4HFRdvLPG3oHv9TQxy6fyl5Pd2Rr/mxmCBBpsRY8KgbmyQIECHAYxs+fq9hD4 6bGBlHOzTA/Y23dWxOVtXH+LwbwFLhAK1eqkq/YwerCdTxr05G8K21TQrOmk6ziv NXpLsT2u64Sy5atB6BTdvzBgEZt6ZU3SYfXylXZc3UDkrb7UTCT3YxoHsBvxMVr4 2PSfPL7VS7z590812n0nNnXETtVybsXyrrTxkvz7YXPb6MWUZAJfM4c7KNzydPSg 8iKOhPHzDv02O3fe9nqsBZkfW6Q1l0UGwEdgF+Cn/vbwpf3E1Csb3b0gl0Ynf8fP FZC6AjAZqsDaB6DcwVnx66kRnhopeTjVf2MIua/x+nOE0Jq1oevxD/IPOQBAElHG DN5BsEQqrgcnF7+w5Nmenv4Yp1h8MxwAgKYqTOZZM2yHsy0Ga2FEFeX75jpLn7q6 ztysV/j0IfBoHjnqp/mFe0QB2c7/1eNw5YstfxtK+SGK/8WcJQ4CJShadq9sLh40 DfQoiW8Bag0eZKJj1d5JI8UX78CNk390aKIHOVXbaFTkg7hvGlb3xNhBMoDCUk1L s4SA+6m4BJOjRdUdO6c92Dsa05V6HDVooQMbxTARaLbyTp5p4es= =YK4p -----END PGP SIGNATURE----- --bcXUUgXyBxMypY1vtyojywUt7yZ47nI5b-- From nobody Mon Feb 26 01:10:01 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB80126BF6 for ; Mon, 26 Feb 2018 01:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 RieKcS15cHS4 for ; Mon, 26 Feb 2018 01:09:58 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 E6C0C1204DA for ; Mon, 26 Feb 2018 01:09:57 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1eqEnB-0007ws-7Y; Mon, 26 Feb 2018 10:09:53 +0100 Date: Mon, 26 Feb 2018 10:09:53 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Michael Richardson cc: Security Area Advisory Group In-Reply-To: <10478.1519411521@obiwan.sandelman.ca> Message-ID: References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> <10478.1519411521@obiwan.sandelman.ca> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 09:10:00 -0000 Hi Michael What particular use case do you have in mind? If people talk already with eachother (to compare fingerprints), I would assume they are already in agreement on a language they talk with each other, which then is the natural option to be used for trustwords. Or do have use cases in mind where said language is not available for trustwords? cheers, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Fri, 23 Feb 2018, Michael Richardson wrote: > > Bernie Hoeneisen wrote: > > 4) The keywords will be available in many languages as opposed to English > > only > > I guess if two people speak different languages, then a mapping could exist > between languages? > > While some might think this is too trivial for the IETF, I am rather in > favour such a specification. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > From nobody Mon Feb 26 08:56:28 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F981200FC for ; Mon, 26 Feb 2018 08:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 Gnx6tl8zO4Wh for ; Mon, 26 Feb 2018 08:56:26 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF95124319 for ; Mon, 26 Feb 2018 08:56:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E7AE520091; Mon, 26 Feb 2018 12:04:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E7C8280D06; Mon, 26 Feb 2018 11:56:24 -0500 (EST) From: Michael Richardson To: Bernie Hoeneisen cc: Security Area Advisory Group In-Reply-To: References: <2140FE22-38DB-4545-B623-D1121DA281D1@gmail.com> <10478.1519411521@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 16:56:28 -0000 --=-=-= Content-Type: text/plain Bernie Hoeneisen wrote: > What particular use case do you have in mind? > If people talk already with eachother (to compare fingerprints), I would > assume they are already in agreement on a language they talk with each > other, > which then is the natural option to be used for trustwords. That's a good point... it's certainly true if they are in direct communication. It would not be true if I was authenticating a key printed in a newspaper in a language I did not speak. I guess it's enough if the UI can change languages, and the user can attempt to pattern match languages they do not speak. > Or do have use cases in mind where said language is not available for > trustwords? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqUPDgACgkQgItw+93Q 3WVZeAgAqzGExhqxq2r/tF0a5X93EW2oHSegCTN9N2rivRf3e1PogA20RDOJmNNX q7cbre1+IYod0q5JPEJSCMp9dCJx3Tbt495HsT4XDdYJ/vomt9TWdXCuz0AoXR37 xBcQ36WeBMT3Hw7j6R61tKCCUbZHZ7nQUCUT4+7L6t+4SI0BwA4e6DCCBVEOsNcD zlvjA/Box1NAwx9TnuiIMWPoOIzfporvqnwCTkP5ZibIvclXRkJJItYqcgmM4App ckdeLsus3o5r238gE6m5pb+6vpG2p0LetowgRre3ARw5uAHSPo8uaJ4uzD4VfeI8 OhhGbjFh8+GRn0Z3Ut8A9phKK2zcDQ== =9R+N -----END PGP SIGNATURE----- --=-=-=--