From nobody Sat Jan 5 11:21:44 2019 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 0BAD1130E36 for ; Sat, 5 Jan 2019 11:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable 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 wU0lVP-E-tWd for ; Sat, 5 Jan 2019 11:21:39 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A436130E64 for ; Sat, 5 Jan 2019 11:21:39 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0F7EE88306; Sat, 5 Jan 2019 19:21:38 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-54.brq.redhat.com [10.40.204.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9CFDE600C0; Sat, 5 Jan 2019 19:21:35 +0000 (UTC) To: "Salz, Rich" , Mark O , "saag@ietf.org" References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> From: Paul Wouters Openpgp: preference=signencrypt Message-ID: Date: Sat, 5 Jan 2019 14:21:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Sat, 05 Jan 2019 19:21:38 +0000 (UTC) Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2019 19:21:43 -0000 On 12/31/2018 03:05 PM, Salz, Rich wrote: > I think it is silly to have an automated security.txt that doesn't have TLS. Whether it uses TLS or not is completely irrelevant. The security contact is supposed to be easy to find public information. What attack is forcing the use of TLS supposed to prevent? The server is already compromised (hence the need for the info) so it is easier to modify the source, then modify it in transit. On a compromised server, you cannot trust the information regardless of PGP, TLS or anything else. I think it is irresponsible to use a security contact provided by a compromised device to report on the compromise and it is irresponsible for the IETF to standardize such a flawed approach that decreases security. If it was harmless, I wouldn't care, but it actually is problematic. Anyone who thinks this is a bad idea, _still_ has to provide a security.txt if it becomes a standard, and somehow has to keep monitoring the content/status of those files for each webserver they run to prevent disclosures from reaching the hackers. Hackers who might realise that they are caught and rm -rf the server in an attempt to hide their tracks. Additionally, it will have all of the same issue of whois contact information: - outdated, unmaintained - spammed to hell - encrypted emails can no longer be read due to person no longer works there, passphrase or private key lost Put this information into RDAP or DNS instead, as those resources are not linked to compromised web resources themselves Paul From nobody Mon Jan 7 05:23:06 2019 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 14103130ED6 for ; Mon, 7 Jan 2019 05:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 FuexfQAwxJWO for ; Mon, 7 Jan 2019 05:22:56 -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 796AF130EE5 for ; Mon, 7 Jan 2019 05:22:54 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x07DHkLV026684; Mon, 7 Jan 2019 13:22:52 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=KriSHbwK8IobUVD96T/YZxotSvmAxute7i/ItgNrXnU=; b=Bxi2qGM2pa0kl33g+85wcCAuwfzGezLwpAf+Q4EsvMbmerf24onKfN251F/48Xgt6kKD K3K9Np8KMdDBXArvXi5jPijKnByJkQC7ABloqwNnfno+84dwFREei5bP8C5bwU9EDbYT mfjOg9qQDaDGUmU5Sgco6V6Vh89xDSROR9USRi989vICb56KOTXlMnUvgH5bB6y37mmo mJDwQsqUWiYG6Ea1qa6arZ5T+tlvBWW/AjZhGizl7KTSg45bklZUZG7QyNyZ7UChwXT8 Giz6tEji/eLeoByqaXWB/hsJ2I4CrZ+06FzzMaZhrzZBcvmsJAu/lDpdiICLc5StzYkP LA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ptn3wppj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 13:22:52 +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 x07DHhtb005681; Mon, 7 Jan 2019 08:22:51 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ptrt1xwhc-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 08:22:51 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 7 Jan 2019 07:22:51 -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.1365.000; Mon, 7 Jan 2019 07:22:51 -0600 From: "Salz, Rich" To: Paul Wouters , Mark O , "saag@ietf.org" Thread-Topic: [saag] Comments on draft-foudil-securitytxt-04 Thread-Index: AdSXmuqMkZbdVjQnQ92VKibJ8bVUvgFZp54AARaYY4D//+EsgIAII1EAgAJsnQA= Date: Mon, 7 Jan 2019 13:22:50 +0000 Message-ID: <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.253] Content-Type: text/plain; charset="utf-8" Content-ID: <2396E807F46C304B81895E898C4126F1@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_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=910 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070118 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_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=904 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070118 Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 13:23:01 -0000 DQo+ICAgICBXaGV0aGVyIGl0IHVzZXMgVExTIG9yIG5vdCBpcyBjb21wbGV0ZWx5IGlycmVsZXZh bnQuIFRoZSBzZWN1cml0eSBjb250YWN0IGlzIHN1cHBvc2VkIHRvIGJlIGVhc3kgdG8gZmluZCBw dWJsaWMgaW5mb3JtYXRpb24uIFdoYXQgYXR0YWNrIGlzIGZvcmNpbmcgdGhlIHVzZSBvZg0KPiAg ICBUTFMgc3VwcG9zZWQgdG8gcHJldmVudD8gVGhlIHNlcnZlciBpcyBhbHJlYWR5IGNvbXByb21p c2VkIChoZW5jZSB0aGUgbmVlZCBmb3IgdGhlIGluZm8pIHNvIGl0IGlzIGVhc2llciB0byBtb2Rp ZnkgdGhlIHNvdXJjZSwgdGhlbiBtb2RpZnkgaXQgaW4gdHJhbnNpdC4NCiAgIA0KWW91IGFyZSBh c3N1bWluZyB0aGF0IGFsbCBub3RpZmljYXRpb25zIGFyZSBlcXVpdmFsZW50IGFuZCB0aGF0IHRo ZXkgYXJlIGFsbCBvZiB0aGUgInlvdSBhcmUgY29tcGxldGVseSBicm9rZW4iIG5hdHVyZS4gIEkg YW0gbm90Lg0KDQoNCg0K From nobody Mon Jan 7 06:20:20 2019 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 157F5130EA1 for ; Mon, 7 Jan 2019 06:20:19 -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=unavailable 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 14ArGYp1kW_u for ; Mon, 7 Jan 2019 06:20:11 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 51F3B1277CC for ; Mon, 7 Jan 2019 06:20:11 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id y16so306096qki.7 for ; Mon, 07 Jan 2019 06:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DSYZT3t3CMQPniahdFpsPwzdV8O+PzFTlABxvy4zQUk=; b=OS4FES6XXsWwQsQU+az1s5NNFL4cT1an/d6Zo9E1kYqst1hnEmLKqet8td7kWCFP9W n8Ot3icEHstFXlQbpqcPF5SHMXZ7sg+ffbWjJ8NL1hC5yHWkIxSLnVVv+5IXNpdjvcSl Gv6XCBhh+PHzux6kK6b0fhnzo7bqSGfSuVhCENTOu5gOSk0lxec95PC24YeI2leOsVVH si+0vARotqupcDgW0iSG+PJ/+iKaeEaKiFb5bqv9oSLL8583yadIOgYDu3fSdpVXj4ng Lp/2QrYSommF8Ufm9QWT+htV+9RNAzwgyeX2ntqmPIktpcWtKk2lEQYu8uIccJYmNxEW iGrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DSYZT3t3CMQPniahdFpsPwzdV8O+PzFTlABxvy4zQUk=; b=FoIkow5Vk3RC7FarxF3yLBFlBGAArJnnpOy7E+aUQkH5POnWkV0MuuWAmHRQKdIEiN zf8VIku8WSGKPaCViR1uYicEFm32lse1f2UK1pWfON+4thjqAOs3wcgymnwxZAOtZP8Q 6SNh0AXl0SQlgtKinnGek27UMMP1nx+x3P1FWiwdj16kGmg0EIP27ULOpOXlaDBVu/yu jXfHFcZtlc0kUKb2thPfU76QdVJdE2Dcp8GTvQ3t57+zgqAYLt1REKuqs7TpQ93uKSJG kN8WnpNPaT16J388kUMJGthb+sGs594dViIm+YRcONI/yUXv7G/tyuEPH4c6JbfpKDkW cELw== X-Gm-Message-State: AJcUukdfOID23dh4sWUZ2S3HG+8AmerGrL2xZA6Pl1LoISMUuRYjW7si 7qvIDvs3ZOa9pYeKaQlq0dA= X-Google-Smtp-Source: ALg8bN7HeiXlomllxUQizoe7nU8L3tW1Bo7Pzq6pcydqORuL6n0tzq3w0cHtQOlZH8UFQ4UGo2zAgw== X-Received: by 2002:a37:6982:: with SMTP id e124mr58027271qkc.50.1546870810478; Mon, 07 Jan 2019 06:20:10 -0800 (PST) Received: from ?IPv6:2600:380:5957:a999:7148:2fd2:a5bc:8046? ([2600:380:5957:a999:7148:2fd2:a5bc:8046]) by smtp.gmail.com with ESMTPSA id q5sm53794398qtq.20.2019.01.07.06.20.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 06:20:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> Date: Mon, 7 Jan 2019 09:20:08 -0500 Cc: Paul Wouters , Mark O , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> To: "Salz, Rich" Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 14:20:19 -0000 Sent from my mobile device > On Jan 7, 2019, at 8:22 AM, Salz, Rich wrote: >=20 >=20 >> Whether it uses TLS or not is completely irrelevant. The security cont= act is supposed to be easy to find public information. What attack is forcin= g the use of >> TLS supposed to prevent? The server is already compromised (hence the n= eed for the info) so it is easier to modify the source, then modify it in tr= ansit. >=20 > You are assuming that all notifications are equivalent and that they are a= ll of the "you are completely broken" nature. I am not. And if it=E2=80=99s another server in the domain that=E2=80=99s compromised r= ather than the server with this file, having the information available for c= ontact is useful. FIRST lists lack of contact information as one of the top 3 challenges of in= cident responders still. This and other methods of making contact informati= on accessible could be quite helpful in reducing the number of compromised s= ystems overall. Best regards, Kathleen=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Jan 7 10:45:59 2019 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 36C09131000 for ; Mon, 7 Jan 2019 10:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable 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 zfmp_jVo6JNO for ; Mon, 7 Jan 2019 10:45:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 DCD38131002 for ; Mon, 7 Jan 2019 10:45:55 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ggZuG-0002To-5A; Mon, 07 Jan 2019 18:45:48 +0000 Date: Mon, 07 Jan 2019 10:45:47 -0800 Message-ID: From: Randy Bush To: Kathleen Moriarty Cc: "Salz, Rich" , Mark O , "saag@ietf.org" In-Reply-To: <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.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] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 18:45:58 -0000 > FIRST lists lack of contact information as one of the top 3 challenges > of incident responders still. This and other methods of making > contact information accessible could be quite helpful in reducing the > number of compromised systems overall. strongly agree that improving contact and associated information is a forever goal, and one we could take some steps on now. but rich is right, doing so in a manner which could be trivially secured but isn't is pretty silly. randy From nobody Mon Jan 7 15:06:10 2019 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 DEC7612E04D for ; Mon, 7 Jan 2019 15:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (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 ChBx-6atk8T5 for ; Mon, 7 Jan 2019 15:06:06 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.208]) (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 E7AA912D4ED for ; Mon, 7 Jan 2019 15:06:05 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-d.us-east-1.aws.symcld.net id 78/31-24968-C5BD33C5; Mon, 07 Jan 2019 23:06:04 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEJsWRWlGSWpSXmKPExsWSoa9gpBt92zj GYN5pXYuGnfkWp89cZLZ41vqSyWJKfyeTA4vHiWVXWD12zrrL7rFkyU8mj6kzZzMGsESxZuYl 5VcksGb0PnzHUtDjWvF67jzWBsbPjl2MXBwsAj3MEke37WYFcYQE+pkkfvc0ATmcQM49RonO6 YwgNpuAgcS1vceZQGwRgVCJ86+usYHYzAJBEu1LH4HVCAtYS/w6uIsVosZGYtKWa1B2skTbu0 YWEJtFQEXi244fYL28ArESq77eZIRYfJdZou/yL2aQBKeAlsTZtZPBbEYBMYnvp9YwQSwTl7j 1ZD6YLSEgIvHw4mk2CFtU4uXjf6wQ9TEScz8fgoorSlzduIIRwpaVuDS/G2yZhEAzu8T7zq1Q CV2JD1OnAi3jALJ9JW690oKouc0osbZlCzNEjZbErqW3GSFqciTeHZeACMtILL7bDXXPXDaJ/ S+sIQGXIjFlFcwNchKreh+yQMx8wiSx9HI7GyS0pCTuXulknMCoOQvJb7OA6pgFFjBKHD78j3 0WOJQEJU7OfMICUaQrsWvfAWYIW15i+9s5QDY7kG0jsSUFIqooMaX7ITuEbSbRdu4j2wJGjlW M5klFmekZJbmJmTm6hgYGuoaGRkBa19DMSC+xSjdFr7RYNzWxuETXUC+xvFivuDI3OSdFLy+1 ZBMjMOWlFHAt2sH4bmn6IUZJDiYlUd5Z+cYxQnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4U28C5 QSLUtNTK9Iyc4DJFyYtwcGjJMIbAZLmLS5IzC3OTIdInWI05lg1o2MGM8fxzq9zmIVY8vLzUq XEef+ClAqAlGaU5sENgmWFS4yyUsK8jAwMDEI8BalFuZklqPKvGMU5GJWEeZlBpvBk5pXA7Xs FdAoT0CkveQxATilJREhJNTAG9O7wrQ+onZm7MEM9M/WSROvv2XFTPfyT9fbdU3320IpP0b1n 3vn5Kd8nfL+mtfGgwqK7ZWkuf6bVrbzpddv1esDdNYVWP2zPH1ohdsHL9otmBI/1Bql+fuEwh bArM5ZJv4j58HTvwhovD1uTeSKPfMVa5r9qvfZNy+HIhb4ZU20zdmoIVH9XYinOSDTUYi4qTg QA2zg24gUEAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-7.tower-424.messagelabs.com!1546902362!4448738!1 X-Originating-IP: [104.47.32.50] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5767 invoked from network); 7 Jan 2019 23:06:03 -0000 Received: from mail-sn1nam01lp2050.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (104.47.32.50) by server-7.tower-424.messagelabs.com with AES256-SHA256 encrypted SMTP; 7 Jan 2019 23:06:03 -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:X-MS-Exchange-SenderADCheck; bh=Yniqr+6952mccNHI00ChETxM4+GsLkzPUtU/nHLaGjY=; b=fheC+QMmgg+SvcZPPuCcLFSAWd52tsQEek4+niH8862BALWWr+Zj7j12z/7+LMZg1RrG/FKhNE+hJYHdd7h0vS4xCPm6QWyByI+C8oOE+EC/FBW3LImUZBAHngBeO7C+lgWeFux+j/YzvYm6p12r4FSJQ8AUxM5yTo+xDQRFNT8= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1267.namprd14.prod.outlook.com (10.173.162.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.9; Mon, 7 Jan 2019 23:05:50 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::60f0:c4cd:7c30:59c4]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::60f0:c4cd:7c30:59c4%2]) with mapi id 15.20.1495.011; Mon, 7 Jan 2019 23:05:50 +0000 From: Tim Hollebeek To: Randy Bush , Kathleen Moriarty CC: Mark O , "saag@ietf.org" Thread-Topic: [saag] Comments on draft-foudil-securitytxt-04 Thread-Index: AdSXmuqMkZbdVjQnQ92VKibJ8bVUvgFNFPcAARWKmxAAB62vAAD578wAAFgN4QAAAgBOAAAJRxiAAAjWqtA= Date: Mon, 7 Jan 2019 23:05:49 +0000 Message-ID: References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.78.193.238] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1267; 6:JhcOMbuOQRKNdM8jbuDt4w+k4QmRIo0cquduIPJfl8wEKRCXkPxwPYtcHFBSdHlF7F92kG37fFVGFfV7I1B1OWTpnF7LhGIA3FH19VWpWNkIy/NOVIx4Ebz1YR0NhyvxrsEzB3DwDgp5GqtOnVqFLsrQAshNHUCvvZbKTXLD7q/tAX8ye1jYFMJBhDYXs9iyffOOPoDqirXv0XKAGxWMsDBcforQdO91dUw770AP/n300EZdVn3ZPegDKFMMDZLYRGCLUom8DgsmJwUW00M6hp8XO3Qq1/8gviEMRpc7iXTuEQDnm55z26gRIuMKmPGB6SLxAE4l9qg6VbyvT4G5iCdEPdm9YsmihKPhpWSlwQXWBBetSvLYh4Gh2tCnhG/g2KanKzSjukd5u7xLr2xVpRspiIwiDKA3+7AL3y+l9xaLVj4Lvz0OjUZfm/oV5AXrKqMcAbMRcGBH8DciDjgRlg==; 5:uJMr2c5fjb4FU6e072k7N6QmtHTG3v6qKy1NtyzJ1edkkrZcsA66DTXVHIANX+b0qyQ7JPnQ8WwZwV7AkVo5uxyeysORb5F0yckC8qZUYJvus0jt0urYzRZqrGxbNJdNe+1m7Z4buuFrAv+ViyZKZ3JlyQUuJ/VchVKBPL3ECo+I6d1N30MO14yQF9fB5WSVDMzUCPeJFT8nQWWfyZpEzw==; 7:p3zM94jB/WExFGT9M0fFUgF8T0WmoP9yh6AH/w1kCh0BAhS2AdURxE/UMy7ETwACTZBeFMyKOQU/op7HWWLxPMf1ludjPuRnXCOQMq+QXJ67beGRF89+0eRKfC5JJuEZnteOayykaERttKDHTuGSDw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: becdd9ae-b5a5-483e-6930-08d674f4aa80 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1267; x-ms-traffictypediagnostic: BN6PR14MB1267: x-microsoft-antispam-prvs: x-forefront-prvs: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(136003)(39860400002)(366004)(346002)(189003)(13464003)(199004)(105586002)(316002)(110136005)(54906003)(6306002)(25786009)(86362001)(4326008)(6246003)(97736004)(446003)(99286004)(9686003)(186003)(14444005)(106356001)(256004)(2906002)(8676002)(71190400001)(55016002)(66066001)(26005)(71200400001)(68736007)(229853002)(6506007)(53546011)(102836004)(486006)(7736002)(93886005)(99936001)(8936002)(7696005)(81156014)(81166006)(44832011)(305945005)(5660300001)(39060400002)(3846002)(6116002)(6436002)(33656002)(14454004)(476003)(74316002)(11346002)(966005)(15650500001)(53936002)(76176011)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1267; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UAfxighopZ9A6GGKwXIVNz2BcyXfWA4VHsgtFb26++aiLPl/iQAuQuhZPRSC3sr8haEV07lRB0vG5YYijBqg5ILnOPlZ2tsjHKit5eD3Bic4niLSNPuowK0jMLzvT6fkVySblFUxKJiMjkGfOq23TiAqJfLhKPDEEFVudxH3cX65CC0Hc2F7UDb/EtG7+gAoVh29bEb/E1n4XSS5fRNd4ZBgED6WysS59z8b2y/gK0TO9lxi/WQanmoFLht8mRvvd7Mx+4g4OfeHinE7Qc8IpxrGuV9GzYM1WOKnMEm9LoUYqg9JVnxN+gvgh7yzTGx5 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_01DE_01D4A6A2.D7B2F790" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: becdd9ae-b5a5-483e-6930-08d674f4aa80 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2019 23:05:49.9777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1267 Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 23:06:09 -0000 ------=_NextPart_000_01DE_01D4A6A2.D7B2F790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree that better security contact information is an important problem and an admirable goal. And I agree that there are some threat scenarios where security.txt might not be compromised and would be able to be relied upon. However, there are also many where it would not be wise to rely upon it, especially early in an investigation where the true extent of the compromise or security issue may be unknown. And I'm sure that the information would inevitably end up being used by many people who lack the sophistication to make a reasonable decision about the likelihood of the information being trustworthy. For that reason, I tend to think that security.txt is a rather nasty footgun, and quite likely to make the situation worse instead of better. I think time is better spent discussing better solutions to the problem. -Tim > -----Original Message----- > From: saag On Behalf Of Randy Bush > Sent: Monday, January 7, 2019 11:46 AM > To: Kathleen Moriarty > Cc: Mark O ; saag@ietf.org > Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 > > > FIRST lists lack of contact information as one of the top 3 challenges > > of incident responders still. This and other methods of making > > contact information accessible could be quite helpful in reducing the > > number of compromised systems overall. > > strongly agree that improving contact and associated information is a forever > goal, and one we could take some steps on now. > > but rich is right, doing so in a manner which could be trivially secured but isn't > is pretty silly. > > randy > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag ------=_NextPart_000_01DE_01D4A6A2.D7B2F790 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 CQUxDxcNMTkwMTA3MjMwNTQzWjAvBgkqhkiG9w0BCQQxIgQgtfgj/KAFZ46umtJibeRwX/U/jU4v Ebsy7j3MDGNWxpUwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAJdVCrb1plHHzlDH4xkSCT3x3dfv3QNNhj2sOBM2hz3le4aiiybwDT7JZGO9LaIX8625IA0Z G3/iMxwTSawXH5zcBlC0+SYqmZLv/PBysZbd8y7MlX1LVLpcugwL1XBHC29sVxLyIR7y5GeyDKPw 1sMry7JZuwcw0GJV/y03LCeQUzL8dJFhwlRstRYe2WNphVJllSTpIZY0v02SzGzD63waeHsZadV2 3M54nTvX7N10Qd77PBYOmaDcjdwF+Ym7VvbhiA6Br6X+tFxCKLx+ZDV22vFYnSnc7fJprBbWo0dN /C60OLt60gmLJ/Vhfr6qjtAZcPdA52RaG2jIRUbRDpYAAAAAAAA= ------=_NextPart_000_01DE_01D4A6A2.D7B2F790-- From nobody Mon Jan 7 18:42:41 2019 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 D842A13103F for ; Mon, 7 Jan 2019 18:42:38 -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, DKIMWL_WL_MED=-0.001, 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 EkEDmTFzHXTM for ; Mon, 7 Jan 2019 18:42:36 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 747C7131038 for ; Mon, 7 Jan 2019 18:42:36 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id g189so1030395pgc.5 for ; Mon, 07 Jan 2019 18:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3b/JjFO0JLeroDsioDcsXRhtuOnAIS18DwFIAcn8w6U=; b=QYIJwn0whZ7gjK64tbjgRohbDWqg9lsrFfj0GEWCpZY91sm1T01erqHaNA1RX4a5LX Y9xVE6218S7Cd0mHRnEUTlktFj3VnRqa+7Hd/ErVGVvUniy37pXDnLNAycC0f7TteSVa 1PkrkYTehfWNsj/ZEU7xnSj7l11Ov78HpYtniFYOVTIp1dYmI8mO6P9ZN7n+6EdIsWu1 Wcvj79J+jHExIEoE/ob5ahwpJ5JPT/ZESbFxu31TCDRlgcaUEWBK20sp1k9i+UHpyibF +IL1cUGQnoO6g/Ag/zuM8Q7y/govdnplJ0+2irPtxp+vwYEjtdyyVJECZP9hGZcD7FD3 V6rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3b/JjFO0JLeroDsioDcsXRhtuOnAIS18DwFIAcn8w6U=; b=b2wHzXLjqJWh3ngGJZ+tXvHZzV2pLrnSUTBAQ3kNoMYaFoeVEyVBw1cQmJxwrLtUX5 NHeKMjfVMMbErTvC6KohkndTtsisO++Q5sIlkRMOcB3jhV968xlL+jvPKpOZvCctBtYh W+8tD20veIkt8kELc6kAp7BcmzypHTtN6krkkvZDPdNYW1EH1lU6GwzmFsTjFinr67ug NNpYqzoXwi84x47tXgIi5MUKMnoCE4ihkCKFA9r2HjNxBhjprxhWkors3UY/FloqbGOn 3v/+SRGG8pWbWnzZOeAQg+Br8+NZfSJ/MnxhKUl4wMryuMuPxT40Ljm+nB9rs2YWu4ti fBOA== X-Gm-Message-State: AJcUukfIsXjMO+EspQQxArCl/Ro1tsmPiPab6jRwrYCDAXAOycc7E0vL dXowFybHNhJ3KmAmNNeeee5oRyeCOJSlLVCBUdhAC7Z0P80= X-Google-Smtp-Source: ALg8bN6euJIpelXHLcCaUioZIvprw4rUZc1FkSLCRny8JG1VIaMnTmBGuSlriM5RIOfR3oJTVlUoJbYhGOkadXfeRhE= X-Received: by 2002:a63:557:: with SMTP id 84mr31303007pgf.411.1546915355044; Mon, 07 Jan 2019 18:42:35 -0800 (PST) MIME-Version: 1.0 References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> In-Reply-To: From: Yakov Shafranovich Date: Mon, 7 Jan 2019 21:41:58 -0500 Message-ID: To: Tim Hollebeek Cc: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 02:42:39 -0000 On Mon, Jan 7, 2019 at 6:06 PM Tim Hollebeek wrote: > > I agree that better security contact information is an important problem and > an admirable goal. > > And I agree that there are some threat scenarios where security.txt might > not be compromised and would be able to be relied upon. > > However, there are also many where it would not be wise to rely upon it, > especially early in an investigation where the true extent of the compromise > or security issue may be unknown. And I'm sure that the information would > inevitably end up being used by many people who lack the sophistication to > make a reasonable decision about the likelihood of the information being > trustworthy. > > For that reason, I tend to think that security.txt is a rather nasty > footgun, and quite likely to make the situation worse instead of better. I > think time is better spent discussing better solutions to the problem. > As of today, there are several places where someone desiring to contact a security team would obtain such information: 1. WHOIS for a particular domain name or IP address. 2. Emailing "security@example.com" as per RFC 2142. 3. Trying to locate a disclosure policy or document on the organization's website. 4. Contacting a CERT or a third party such as HackerOne or ZDI, in hopes that they have a better way to reach out to a particular organization. 5. Trying to find someone who works in a security role at a particular organization via social media such as LinkedIn, and reaching out directly. etc. All of these approaches have their advantages and disadvantages, and it seems that usually a combination of these actually gets the reporter in touch with the correct person at an organization. This proposal is addressing item #3 - all it is providing is a simple way for an organization to publish a security reporting policy on their website in a standard, machine-parsable way, and stored in a standard location. It is certainly not claiming to be more secure than that approach, but at the same time it not less secure than publishing this information on a website directly like it is done today. There are other similar entries in the .well-known registry that use a similar approach of publishing something in a webspace in order to achieve a security-related result. Some examples are keybase.txt, acme-challenge, etc. Yakov From nobody Mon Jan 7 22:05:24 2019 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 08D481310F7 for ; Mon, 7 Jan 2019 22:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 zJFRYcWei8ny for ; Mon, 7 Jan 2019 22:05:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C3C911310F4 for ; Mon, 7 Jan 2019 22:05:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ggkVp-0001fI-SC; Tue, 08 Jan 2019 06:05:18 +0000 Date: Mon, 07 Jan 2019 22:05:17 -0800 Message-ID: From: Randy Bush To: Yakov Shafranovich Cc: Tim Hollebeek , "saag@ietf.org" In-Reply-To: References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.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] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 06:05:23 -0000 > This proposal is addressing item #3 - all it is providing is a simple > way for an organization to publish a security reporting policy on > their website in a standard, machine-parsable way, and stored in a > standard location. It is certainly not claiming to be more secure than > that approach, but at the same time it not less secure than publishing > this information on a website directly like it is done today. https is pretty widely deployed. most of the searches you enumerated are tls protected today. this proposal goes against that for no good reason. if this is not fixed, on last call i will stand with tim and just shoot the damned horse. randy From nobody Tue Jan 8 16:39:36 2019 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 E635512D4ED for ; Tue, 8 Jan 2019 16:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 9g_NaGlwc8K8 for ; Tue, 8 Jan 2019 16:39:31 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FF8124408 for ; Tue, 8 Jan 2019 16:39:31 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CC658D792C; Wed, 9 Jan 2019 00:39:30 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-54.brq.redhat.com [10.40.204.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F5AF60BEC; Wed, 9 Jan 2019 00:39:29 +0000 (UTC) To: Randy Bush , Yakov Shafranovich Cc: "saag@ietf.org" References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> From: Paul Wouters Openpgp: preference=signencrypt Message-ID: <1f05cbe4-7f06-3e7b-aaf3-f8cf71f6f392@redhat.com> Date: Tue, 8 Jan 2019 19:39:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 09 Jan 2019 00:39:30 +0000 (UTC) Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 00:39:34 -0000 On 01/08/2019 01:05 AM, Randy Bush wrote: >> This proposal is addressing item #3 - all it is providing is a simple >> way for an organization to publish a security reporting policy on >> their website in a standard, machine-parsable way, and stored in a >> standard location. It is certainly not claiming to be more secure than >> that approach, but at the same time it not less secure than publishing >> this information on a website directly like it is done today. > > https is pretty widely deployed. most of the searches you enumerated > are tls protected today. this proposal goes against that for no good > reason. if this is not fixed, on last call i will stand with tim and > just shoot the damned horse. This does not make sense to me. If you are presenting security.txt for an HTTP resource, it will naturally be served over HTTP, not HTTPS. The whole point of this thing is that it is present on the resource itself, not somewhere else[.*] If http://example.com is compromised, and you grab http://example.com/security.txt, then whether the content of security.txt points to an HTTP or HTTPS resource is meaningless. You already lost on the initial unprotected download of security.txt (be it by server compromise or active network attacker) You can't have your horse and shoot it too. Paul [*] If you want the security of "somewhere else", you should have started to look there in the first place. From nobody Tue Jan 8 16:57:24 2019 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 CD9FF131207 for ; Tue, 8 Jan 2019 16:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 gaFwyuTG9jPF for ; Tue, 8 Jan 2019 16:57:20 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B26F12D4ED for ; Tue, 8 Jan 2019 16:57:20 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6F74D89AC6; Wed, 9 Jan 2019 00:57:19 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-54.brq.redhat.com [10.40.204.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9EC65D762; Wed, 9 Jan 2019 00:57:17 +0000 (UTC) To: Kathleen Moriarty , "Salz, Rich" Cc: Mark O , "saag@ietf.org" References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> From: Paul Wouters Openpgp: preference=signencrypt Message-ID: Date: Tue, 8 Jan 2019 19:57:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 09 Jan 2019 00:57:19 +0000 (UTC) Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 00:57:22 -0000 On 01/07/2019 09:20 AM, Kathleen Moriarty wrote: > FIRST lists lack of contact information as one of the top 3 challenges of incident responders still. This and other methods of making contact information accessible could be quite helpful in reducing the number of compromised systems overall. I do see value in a domain-wide standardized location for this information, whether it is example.com/.well-known/security.txt or security.example.com or a TXT record in _security.example.com. That still runs the risk of getting compromised, but that risk is far lowed than a security contact per resource in the organization, and even something the organization can monitor for. This of course immediately runs into the problem "what is a separate administrative domain" (aka the public suffix problem) I think random web servers each with a security.txt will result in mostly bad, outdated or malicious information. People lose track of their VMs, their metal servers, or even racks of servers. They won't be able to maintain a list of servers or images with updated security information. And this of course immediately runs into the problem what is a separate administrative domain (aka the public suffix problem) And I don't agree with you on the "something is better than nothing" argument. We already have the SOA record and the whois output and the HTTP contact email, so why would adding another one work better than the ones we already tried before? Put something machine readable in RDAP. It's designed for that. It already properly delegates domains across administrative boundaries. Add a trivial command line tool to query the security information for a domain (that automatically handles cutting prefixes until it gets the right zone cut, so you can just feed it the hostname or IP address you want to report on) Paul From nobody Tue Jan 8 17:07:06 2019 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 1212912D4ED for ; Tue, 8 Jan 2019 17:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 oOk8HLCbUz5B for ; Tue, 8 Jan 2019 17:07:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 B4702124408 for ; Tue, 8 Jan 2019 17:07:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gh2Kh-0003Ph-T7; Wed, 09 Jan 2019 01:07:00 +0000 Date: Tue, 08 Jan 2019 17:06:59 -0800 Message-ID: From: Randy Bush To: Paul Wouters Cc: Yakov Shafranovich , "saag@ietf.org" In-Reply-To: <1f05cbe4-7f06-3e7b-aaf3-f8cf71f6f392@redhat.com> References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> <1f05cbe4-7f06-3e7b-aaf3-f8cf71f6f392@redhat.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] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 01:07:04 -0000 > If http://example.com is compromised, and you grab > http://example.com/security.txt, don't do that and, in anything but trivial environments, it is foo.example.com that is compromised and the security.txt is on example.com randy From nobody Tue Jan 8 18:02:22 2019 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 E3D6C12F1A2 for ; Tue, 8 Jan 2019 18:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 h8ipb0mJlNQW for ; Tue, 8 Jan 2019 18:02:18 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 17A3112008A for ; Tue, 8 Jan 2019 18:02:18 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id m1so2573000pgq.8 for ; Tue, 08 Jan 2019 18:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YmV+fQuZ4hHyZ9hAEFBoskrbOTs68gWlE2aSD0rfUBI=; b=GgdOV5U3OeiV4UdhEnkeJs8iLwkOlfK4PR6+CYrMSHZia6UuFtUDtIbTqXImTdIHft 6rDL7ERgcrqB920SCAVeaMvHbpTgC2AZ1VFW7LyMfMa7k9qlX847yy8CXGuzcwxuVZOk xz4kNXTNKpr4+MXHlHSl8VQyyOD0BGaTmWMypF/qQYnPTiK04Y0jUf6GK62k62eTGmfT r+Z+UAkNhN77DPMVKlYC9Ak49Zf4lsjtQh7lWBPYfR6xcHik62ARdSUib4R9YXDXSkoc pDreBKmTvv+hWNlxa7442Uk4jbbhoYqUIOfufbl2rQYZSspoCkQKdZKSCUnaaQnQd7tD 7CnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YmV+fQuZ4hHyZ9hAEFBoskrbOTs68gWlE2aSD0rfUBI=; b=jAUDSDh/TmxyfUr+jMUxR+D/bVdAuv7d9OC3fepO2Xfq2KDvKjLoHyZeBxUoblX+4B pi6weSAEIWKed/81HmeJJ94nPVbbvHmrAFzKcTIRmUW5XjY77vDup77Oj//kTHEMYscP PqbpyhGn6GpC9xWEmOwvgSa0KYm1XwNZftZyHRCUoRpT/ziWOpIbZ1Exev/KmjzNyR/7 8nZ91Amr8rALL6ikOjC2eOejUP4p9ZyUJiAyECJfjG5PbDz9s/r/85xCvo2dJA3Uyzn+ 9Jti3Qg34qQKWrSdQV8KOI8RagG+YPul0/D4YymgtUzQvmlRBbZ0EbG9GMahexX+A+6q dAVA== X-Gm-Message-State: AJcUukcqYj8aMLQB4MjOKXBl6im8iOueQhlMeSZimuMWpWyukXNMnqcY +3un+UBfkRvrTzf+IX7rvWlRxxYC00pGLcPKs6k+XQ== X-Google-Smtp-Source: ALg8bN7B2p22T2tkQxbnxo/+RpVknNm8kWPmoF2K4lUOdMoGq39ViYgVBEEyy1xRrr8J9gl04VpqvztX3sZXhc/A6WY= X-Received: by 2002:aa7:8286:: with SMTP id s6mr3985197pfm.63.1546999337073; Tue, 08 Jan 2019 18:02:17 -0800 (PST) MIME-Version: 1.0 References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> <1f05cbe4-7f06-3e7b-aaf3-f8cf71f6f392@redhat.com> In-Reply-To: <1f05cbe4-7f06-3e7b-aaf3-f8cf71f6f392@redhat.com> From: Yakov Shafranovich Date: Tue, 8 Jan 2019 21:01:40 -0500 Message-ID: To: Paul Wouters Cc: "saag@ietf.org" , Ed Overflow Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 02:02:21 -0000 On Tue, Jan 8, 2019 at 7:39 PM Paul Wouters wrote: ... > If http://example.com is compromised, and you grab http://example.com/sec= urity.txt, > then whether the content of security.txt points to an HTTP or HTTPS resou= rce is > meaningless. I want to clarify one point that Ed Foudil discussed with me: are we assuming that this proposal is intended for *vulnerability disclosure* or for *incident response*? Specifically, as per CERT's guide (section 1.2.8): https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340= .pdf "Sometimes the term =E2=80=9CIncident Response=E2=80=9D is used synonymousl= y with Vulnerability Response. These two concepts are related, but different; Vulnerability Response specifically indicates responding to reports of product vulnerabilities, usually via the CVD process, whereas Incident Response is more general and can also include other security events such as network intrusions." This proposal originates from the security research community and is geared towards vulnerability disclosure, and not necessarily things like reporting an active compromise - although it can be used for that purpose. Perhaps that's where the disconnect is. Yakov From nobody Thu Jan 10 06:46:00 2019 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 E2AF9130EEF for ; Thu, 10 Jan 2019 06:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 IZx-29KrctMD for ; Thu, 10 Jan 2019 06:45:56 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EB2130E69 for ; Thu, 10 Jan 2019 06:45:56 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0B64396A; Thu, 10 Jan 2019 14:45:55 +0000 (UTC) Received: from bofh7.nohats.ca (ovpn-204-54.brq.redhat.com [10.40.204.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id E893E5D76B; Thu, 10 Jan 2019 14:45:53 +0000 (UTC) To: Randy Bush Cc: Yakov Shafranovich , "saag@ietf.org" References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> <13AA6D29-CC99-49B6-A671-BFD0E407C507@akamai.com> <2C5F7D9D-47A2-4665-9DC8-58C01A93351E@gmail.com> <1f05cbe4-7f06-3e7b-aaf3-f8cf71f6f392@redhat.com> From: Paul Wouters Openpgp: preference=signencrypt Message-ID: Date: Thu, 10 Jan 2019 09:45:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 10 Jan 2019 14:45:55 +0000 (UTC) Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 14:45:59 -0000 On 01/08/2019 08:06 PM, Randy Bush wrote: >> If http://example.com is compromised, and you grab >> http://example.com/security.txt, > > don't do that > > and, in anything but trivial environments, it is foo.example.com that > is compromised and the security.txt is on example.com First, in _most_ domains, APEX and www. are all there is, and usually the same server. So you have no choice but to grab it from the compromised host. Are you saying this method should not be used at all for the majority of websites because of this limitation? So what if www.nohats.ca is bad and you want to find my security.txt? Turns out www.nohats.ca is the same as nohats.ca. You cannot just curl for the security.txt because you might get redirected to the bad server. And what do you if those are the same? Should the draft talk about this? Also, to me it had not been clear that the intend was to only put it on the main domain and not on each server within the domain. I thought the problem being addressed was that there is ams.nl.service.example.com and that a contact from whois/rdap for the whole example.com would not lead to the right contact, and so instead the server itself would publish a security.txt. But it seems now that people would need to crawl for zonecuts because it is planned to only appear at the apex or "subdomains" as I read it now: The file is named "security.txt", and this file SHOULD be placed under the /.well-known/ path ("/.well-known/security.txt") [RFC5785] of a domain name or IP address for web properties. [Note I had not realised the subtlety of "of a domain name". I think the draft should make it very clear how to handle reporting hosts within a domain using the top level domain. If the idea is that for www.example.com you go to a example.com/.well-known/security.txt it should be made more clear. And then talk about the problem of the apex and www. being the same host] Some examples appear below: # The following only applies to example.com. https://example.com/.well-known/security.txt # This only applies to subdomain.example.com. https://subdomain.example.com/.well-known/security.txt # This security.txt file applies to IPv4 address of 192.0.2.0. http://192.0.2.0/.well-known/security.txt [note: this ending in .0 is very confusing. Is it mean to cover the whole /24 ?] # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. http://[2001:db8:8:4::2]/.well-known/security.txt # This security.txt file applies to the /example/folder1 directory. /example/folder1/security.txt Here, the "subdomain.example.com" hides the problem of not knowing administrative cuts. Is toronto.bank.site a domain or subdomain? What about paul.lawyers.website? what about example.gc.ca ? or example.gc.com ? So where do you now find a security.txt for ams.nl.service.example.com ? It seems the draft now dictates you: - look for a subdomain zonecut for nl.service.example.com - if found, look for /.well-known/security.txt - if not found, look for /security.txt - look for a subdomain zonecut for service.example.com - if found, look for /.well-known/security.txt - if not found, look for /security.txt - look for a subdomain zonecut for example.com - if found, look for /.well-known/security.txt - if not found, look for /security.txt - look for server named .com - if found, look for /.well-known/security.txt - if not found, look for /security.txt And that's before we start talking about how to handle HTTP vs HTTPS resources which could end up on different VHOST configurations. As for the examples for the IP address, I'm also confused. If 193.110.157.66 needs to be reported on, and I should not go to the compromised host itself, so not try http://193.110.157.66/.well-known/security.txt? Do I have to try http://193.110.157.0/.well-known/security.txt or do I try http://157.110.193.in-addr.arpa/.well-known/security.txt ? Also if the /24 is malicious and I want to go "one level up" that's also a really hard problem, because now you need to do DNS queries to see if this is a /24 from a /16 or straight from the RIR. The document should really elaborate on these scenarios. The examples only illustrate more problems, and more possible unclear locations of where to find these. I doubt any of these will ever see a real use because of the problems I cited above. Paul From nobody Sat Jan 12 20:20:10 2019 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 773CD128AFB for ; Sat, 12 Jan 2019 20:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 P6Ax1U4zPo_9 for ; Sat, 12 Jan 2019 20:20:06 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 36847124D68 for ; Sat, 12 Jan 2019 20:20:06 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id a14so8587674plm.12 for ; Sat, 12 Jan 2019 20:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UoHxYjYA6oGeUpjh3PWl1rLZ1ZJ23po8ffDKWKtqI9g=; b=toR5KbbxgY8sZSzUFGepE11jS2dgHGV31x+XPFQwXJnI+GWYyTdwbkGIVqU+7WOweL rDWks5PjLiyVQpvbuLP5I+7cTxtd9dDa/VuY6BRTNNX4Gq2ApaEvg1+MepFE6s5jEvhI eUBZ4rSc7I6jEggrVw4DEcDMLzVn2dSbYyP7UcakiI+rg48288HMpF0G0oH9Gmsilfjz iV7NGoVXHR3wWq8OpnTwd53HnIJNhC527yMADHnJxw+m5S/mDkdTDvwnCDmr/6tKdPfr oO00mB4A4wskt+0lQioPccBp7l9GsFXYNGbOge2zRVFrvcTzoCEYm1Wts//tZBVuGSH5 FUTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UoHxYjYA6oGeUpjh3PWl1rLZ1ZJ23po8ffDKWKtqI9g=; b=GPigSqZ1NAvN0YsTfnLeNoqQ2giMj37gKgDgsq4z3tW5zYwjAvZlOATd/BlyD7Ct5n jrXabHYWw4bLrnCInwlWpdtfRLfBUlMLr4DND1/ukxfsF9ujfaTcA/xRB3uPsYtPc6a2 of8KTyLMLzGKCGzc0j2fQtCaAaSB+Mgex8vT09eNLUDeDPA1hXTkDhWDx6x7taLJEPe5 UQCO+REyXRwYYAJfDQ06GcV9wn9NEq68QS4ffQ6RpLK3NuqN7fUqzOjinUP4E7hzSA4G 0ouWetJi49XeMKQZzNgqTw/oJvm7vjsQPYMWDVoracgXnSeKkNqo31Jp+YBNvft2Gyoi 0xdA== X-Gm-Message-State: AJcUukdWH44w9XaX3PuQdWE8rkEEdHqrRQP3VsgRHv8t6v4AwTJamORk khvGRVlP6/Z9CQNto5fiNzSfyu3vx9iCewU2ucOzyhl6 X-Google-Smtp-Source: ALg8bN7bXMahrwFNU7v/8Ns4u4rX2FhIYJXj52pcuWuEVn8nnnmUjI4huyX5L2JbxckHvstSk2OOvSpjn9r4ZkJLeuU= X-Received: by 2002:a17:902:7581:: with SMTP id j1mr20885304pll.308.1547353205337; Sat, 12 Jan 2019 20:20:05 -0800 (PST) MIME-Version: 1.0 References: <154735294274.20355.12889484136230977530.idtracker@ietfa.amsl.com> In-Reply-To: <154735294274.20355.12889484136230977530.idtracker@ietfa.amsl.com> From: Yakov Shafranovich Date: Sat, 12 Jan 2019 23:19:29 -0500 Message-ID: To: Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Fwd: New Version Notification for draft-foudil-securitytxt-05.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 04:20:08 -0000 ---------- Forwarded message --------- From: Date: Sat, Jan 12, 2019 at 11:15 PM Subject: New Version Notification for draft-foudil-securitytxt-05.txt To: Edwin Foudil , Yakov Shafranovich A new version of I-D, draft-foudil-securitytxt-05.txt has been successfully submitted by Yakov Shafranovich and posted to the IETF repository. Name: draft-foudil-securitytxt Revision: 05 Title: A Method for Web Security Policies Document date: 2019-01-12 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-05.txt Status: https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ Htmlized: https://tools.ietf.org/html/draft-foudil-securitytxt-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt Diff: https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-05 Abstract: When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format ("security.txt") to help organizations describe the process for security researchers to follow in order to report 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 Jan 14 06:04:46 2019 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 2A351131065; Mon, 14 Jan 2019 06:04:44 -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=isode.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 lcjrqzmk4sdu; Mon, 14 Jan 2019 06:04:42 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 772AE129A87; Mon, 14 Jan 2019 06:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547474678; d=isode.com; s=june2016; i=@isode.com; bh=B/rY3XrPyAnyWjadOGJQd8Py5puayZwa9Vv2lyEOO8o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=q8OlI9tQLLsjDAro3gt9S1bYrOJw2T+klRRheASsIIrvRi2ogIp+r/TyMueqvhDRscuJ+U /5je8J7YOUHVpexadkTvXm6ldzs82wgIdZCeKYLCw3QwgO2DIWu48r/CSp1+wVeRhnauTc EaZlJEMA9Crfz7Axb3EPFEyYDyVWQto=; Received: from [192.168.0.7] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 14 Jan 2019 14:04:38 +0000 To: Peter Gutmann , "draft-gutmann-scep@ietf.org" , "carl@redhoundsoftware.com" Cc: "saag@ietf.org" References: <152231658869.24008.11321959845877039592.idtracker@ietfa.amsl.com> <1522887334433.4490@cs.auckland.ac.nz> <1525092187804.38190@cs.auckland.ac.nz> <1531471734017.88813@cs.auckland.ac.nz> From: Alexey Melnikov Openpgp: preference=signencrypt Message-ID: Date: Mon, 14 Jan 2019 14:04:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 In-Reply-To: <1531471734017.88813@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [saag] Comment added to draft-gutmann-scep history X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 14:04:44 -0000 Hi Peter, My apologies of dropping the ball on this. My replies below: On 13/07/2018 09:49, Peter Gutmann wrote: > Alexey Melnikov writes: >=20 >> 1) I need help with you flagging to me which text was modified in the pas= t >> due to comment. I might agree or disagree with these changes and they mig= ht >> be highlighting sections which might need more work anyway. >=20 > Ahhh... how much of a list do you want? There's an awful lot of emails to= go > through (maybe two years' worth of comments) to sort it all out, and most = of > it is pretty uninteresting. If you're OK with dealing with it on a case-b= y- > case basis (e.g. "this particular bit of text was based on comments about = X > and Y") that would make it easier. >=20 >> If you can convince me that #2 is not an issue, then I suggest adding a n= ote >> to the document saying that it is using a bunch of MIME types that are no= t >> registered (or have different registered aliases, but used here for histo= ric >> reasons). I am happy to suggest some text. >=20 > That would be good, thanks. Since it's a case of "Types in this tree cann= ot > be registered", I don't see how they could be registered without renaming > them, which breaks compatibility with all existing implementations, and th= e > primary goal of the draft was to keep it bits-on-the-wire identical to wha= t's > been in use the entire time (modulo single DES + MD5 vs. AES + SHA-2). Add a new paragraph to the end of Introduction: Note that SCEP doesn't follow best current practices on usage of HTTP. In particular, it is using unregistered Media Types, it recommends ignoring Media Types and hardcoding spefic URI paths. > In terms of: >=20 >> 2) if I have a general Web Server that happens to return different MIME t= ypes >> here (because there are other already registered MIME types that mean the= same >> thing), is this going to be a problem for SCEP clients? >=20 > I don't think so for two reasons, firstly I'm not aware of anyone actually > doing SCEP using a standard web server, it's always a standalone SCEP > application that isn't a web server (if anyone is implementing SCEP as a C= GI > for a conventional web server, please speak up, I've never heard of one), = and > secondly I don't know if anyone actually looks at the MIME types. I would= n't > want to put money on that, no doubt some client or other will break if you > change the strings, but I'd say that a lot of clients won't care what the > value is. > >> I think either ABNF (which is pretty universally used in IETF RFCs) or in >> free text form which sort of looks like HTTP request line, but isn't. Ple= ase >> pick one and I can suggest some small specific edits to reflect that. >=20 > That would be really useful, thanks. I think ABNF is best. Below are all ABNF related changes that I suggest. (Examples in your document are not affected): Add a new sentence to the end of: 1.1. Conventions Used in This Document This document uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF] for defining formal syntax of commands. Non terminals not defined in this document (for example "HTTP-version") are defined in either [ABNF] or [RFC7230]. 2.1.1. Client Replace: OLD: 2. The CA HTTP CGI script path (this usually has a default value, see Section 4.1). NEW: 2. The CA HTTP SCEP path (this usually has a default value, see Section 4.1). 3.5.1. GetCACaps HTTP Message Format Replace: OLD: This message requests capabilities from a CA, with the format: "GET" CGI-PATH CGI-PROG "?operation=3DGetCACaps" NEW: This message requests capabilities from a CA, with the format: "GET" SP SCEPPATH "?operation=3DGetCACaps" SP HTTP-version CRLF 4.1. HTTP POST and GET Message Formats Replace: OLD: SCEP uses the HTTP "POST" and "GET" messages to exchange information with the CA. The following defines the syntax of HTTP POST and GET messages sent from a client to a CA: "POST" CGI-PATH CGI-PROG "?operation=3D" OPERATION "GET" CGI-PATH CGI-PROG "?operation=3D" OPERATION "&message=3D" MESSAGE where: o CGI-PATH defines the path to invoke the CGI program that parses the request. o CGI-PROG is set to be the string "pkiclient.exe". This is intended to be the program that the CA will use to handle the SCEP transactions. o OPERATION depends on the SCEP transaction and is defined in the following sections. The CA will typically ignore CGI-PATH and/or CGI-PROG since it's unlikely to be issuing certificates via a web server. Clients SHOULD set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA. The CA SHOULD ignore the CGI-PATH and CGI-PROG unless its precise format is critical to the CA's operation. NEW: SCEP uses the HTTP "POST" and "GET" HTTP methods [RFC7230] to exchange information with the CA. The following defines the ABNF syntax of HTTP POST and GET methods sent from a client to a CA: POSTREQUEST =3D "POST" SP SCEPPATH "?operation=3D" OPERATION SP HTTP-version CRLF GETREQUEST =3D "GET" SP SCEPPATH "?operation=3D" OPERATION "&message=3D" MESSAGE SP HTTP-version CRLF where: o SCEPPATH is the HTTP URL path for accessing CA. Clients SHOULD set SCEPPATH to the fixed string "/cgi-bin/pkiclient.exe" unless directed to do otherwise by the CA. o OPERATION depends on the SCEP transaction and is defined in the following sections. o HTTP-version is the HTTP version string, which is "HTTP/1.1" for [RFC7230]. o SP and CRLF are defined in [ABNF]. And finally you add ABNF RFC (RFC 5234) and RFC 7230 (HTTP/1.1) to the Normative References section. >=20 >> I would like to use ABNF terminal for this and only explain that the path= is >> typically as you describe only in one place in the document.=20 >=20 > OK, will that be part of the text above? If you've got some appropriate > wording to put in that'd be helpful. >=20 >> As above: pick between ABNF and free form text and I can suggest some >> specific edits. >=20 > ABNF, thanks. >=20 >> So AES and SHA-2 are absolutely Normative references. >=20 > OK, I've added AES and SHA-2 refs. >=20 >> I am actually Ok with no mentioning ACME, but the text in the introductio= n >> reads like it is arguing that SCEP is the best thing since bread and butt= er >> and I don't believe what it is trying to say is accurate. >=20 > Hmm, it's just saying that it's widely used, which is why it's being > documented, it doesn't try and claim it's particularly good... the compari= sons > to CMP and CMC didn't appear until draft 17, with more changes in wording > around draft 22. As far as I know this wording was purely political, PKIX > wanted everyone to use their CMP or CMC protocols and so the references we= re > added to appease PKIX. Since the market appears to have made their choice > between { CMP, CMC, SCEP }, it's probably easiest to just remove any menti= on > of them, so that I don't have to engage in a comparative analysis of who k= nows > how many different management protocols (there's a lot more than CMC and C= MP > out there now). So I can just remove that entire paragraph apart from the > first sentence and merge that with the previous paragraph: >=20 > -- Snip -- >=20 > X.509 certificates serve as the basis for several standards-based security > protocols such as TLS, > S/MIME, and IKE/IPsec. When an X.509 > certificate is issued there typically is a need for a certificate manageme= nt > protocol to enable a PKI client to request or renew a certificate from a > Certificate Authority (CA). This specification defines a protocol, Simple > Certificate Enrolment Protocol (SCEP), for certificate management and > certificate and CRL queries. >=20 > -- Snip -- >=20 > That's a pretty basic statement of functionality without trying to get int= o a > comparative analysis of a load of different protocols and mechanisms, and = one > which will hopefully upset the least number of people. This text looks much better to me. >>> I have no idea... I mean I literally have no idea, I don't know what >>> implementations do in practice. I know that in some cases with manual >>> approval it can take hours, but I'm not sure if that's typical. It coul= d be >>> seconds, minutes, hours... >> >> I suspect you will get a blocking DISCUSS comment on this in IESG review.= But >> if you want to take your chances, I am Ok with no change. >=20 > I've added the following, which formalises what's in the above sentence: >=20 > The frequency of the polling operation is a CA/client configuration issu= e, > and may range from seconds or minutes when the issue process is automati= c > but not instantaneous, through to hours or days if the certificate issue > operation requires manual approval. This is better, thank you. Best Regards, Alexey From nobody Tue Jan 22 17:36:36 2019 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 0C8F812F1AC; Tue, 22 Jan 2019 17:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 58TA_dq07TUF; Tue, 22 Jan 2019 17:36:32 -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 0B33412D4E7; Tue, 22 Jan 2019 17:36:31 -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=1548207392; x=1579743392; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A6BSXE76Sv13L4+frph1/jTy4dJm/hv9xhXgtDDftmM=; b=0GWQUQ96A0FPDpgXXDOBPLD64rXBHZskStaesvASbyb/iNTKlzqOoiok eQYKhbwiwLAq9zDuAO7SQhiNvIS2fiUPSIh4HSV65yuzh2O1JN32xgH3P un9G5+PDNRL+meWJ+XgJf3Ysoq6NQTs9glVJWn7JvZrGK5d0Sk2dVD+9d oqTBV2BKjUHkdOpelR62//dV7C81SjA8x0s3BmbYZXCkUup4R/EW2IwqU lblUq5ELEiUckCua5pKrfdrvQWaf5RlUBlzL2Ck1/gsNy+RTSVn2ePmFK ZjWvLvGfkcNIClDeQ7OA00LAocPPq/UsZWMA5KJQP+fcO91ykmP3YaZq2 Q==; X-IronPort-AV: E=Sophos;i="5.56,509,1539601200"; d="scan'208";a="46233441" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Jan 2019 14:36:25 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 23 Jan 2019 14:36:25 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 23 Jan 2019 14:36:24 +1300 From: Peter Gutmann To: Alexey Melnikov , "draft-gutmann-scep@ietf.org" , "carl@redhoundsoftware.com" CC: "saag@ietf.org" Thread-Topic: [saag] Comment added to draft-gutmann-scep history Thread-Index: AQHTx0JalykNlRFNLEeHWmw80fOk66PxVi1qgCgcEDyAL8YogIBEQ8VngSI/joCADi2UOw== Date: Wed, 23 Jan 2019 01:36:24 +0000 Message-ID: <1548207354255.65634@cs.auckland.ac.nz> References: <152231658869.24008.11321959845877039592.idtracker@ietfa.amsl.com> <1522887334433.4490@cs.auckland.ac.nz> <1525092187804.38190@cs.auckland.ac.nz> <1531471734017.88813@cs.auckland.ac.nz>, 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] Comment added to draft-gutmann-scep history X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 01:36:35 -0000 Alexey Melnikov writes:=0A= =0A= >My apologies of dropping the ball on this. My replies below:=0A= =0A= Thanks, working on the update now. Should I send a copy back to you to che= ck=0A= it's OK, or just post the new draft?=0A= =0A= Peter.=0A= From nobody Wed Jan 23 02:28:32 2019 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 B3A5612F1A6; Wed, 23 Jan 2019 02:28:30 -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=isode.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 goDBqfsh_UHE; Wed, 23 Jan 2019 02:28:29 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 43D5E12F1A2; Wed, 23 Jan 2019 02:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1548239308; d=isode.com; s=june2016; i=@isode.com; bh=AnCfOTCY/fqrnQ2YPR33vgR/lkjLhvqACrpP4BBE6Ns=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IFbSYa9+1JCBXv0gUlF2Q9hy3Vg5+svUr+3J3S1l50BBQcXJznzm7gY3op9BB1OwXdwJaz mlaT+YPbhxAsvd77c97+XvA5AVhJbL3b1MChwmPT4YJjrdlWNywh1Z6mTBSf5dtLVbmRYQ ZzBfSmnZs8eCHCVyLJCYJ444qCfK8MY=; Received: from [10.211.200.237] ((unknown) [85.255.236.231]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 23 Jan 2019 10:28:28 +0000 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov X-Mailer: iPhone Mail (15G77) In-Reply-To: <1548207354255.65634@cs.auckland.ac.nz> Date: Wed, 23 Jan 2019 10:28:25 +0000 Cc: "draft-gutmann-scep@ietf.org" , "carl@redhoundsoftware.com" , "saag@ietf.org" Message-Id: References: <152231658869.24008.11321959845877039592.idtracker@ietfa.amsl.com> <1522887334433.4490@cs.auckland.ac.nz> <1525092187804.38190@cs.auckland.ac.nz> <1531471734017.88813@cs.auckland.ac.nz> <1548207354255.65634@cs.auckland.ac.nz> To: Peter Gutmann MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Comment added to draft-gutmann-scep history X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 10:28:31 -0000 Hi Peter, > On 23 Jan 2019, at 01:36, Peter Gutmann wrote:= >=20 > Alexey Melnikov writes: >=20 >> My apologies of dropping the ball on this. My replies below: >=20 > Thanks, working on the update now. Should I send a copy back to you to ch= eck > it's OK, or just post the new draft? Just post a new draft. Thank you, Alexey From nobody Thu Jan 24 02:10:06 2019 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 30D3B1310CB for ; Thu, 24 Jan 2019 02:10:05 -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 OMyg1J2y5Cqh for ; Thu, 24 Jan 2019 02:10:03 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 82133130E65 for ; Thu, 24 Jan 2019 02:10:03 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id c2so4197325iom.12 for ; Thu, 24 Jan 2019 02:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=XWQo9luhHdVFPE4Rj01C3JoBhMnOD5GIOiP7elmdfMs=; b=qnWOtp2E60/dZbnE8qWUwgLtrA2GZVvVFTPaNtUTaHQlAvoKi1NIJB4GisWT+1Ogt1 TpPn21rcxFCjjtcPczBmCvay8szHhZ/R9vdWL6AKuQLHoZL5SfrvTAsqXbUmdh7w6995 262AVBK9invkUw1TUcBnK0BBcCXn6gp1Pb1NK87Hs1OwNsVLKuePlcUfPjXQqVozP73J M/pcs7uHl73DuT1yi1fThKoY2CCiP4nb2IWUpDonYuwUk2Sq4jyVjHgM+hwmcFsC54Hc Xosc4g91zIocYd9KORMKmOKLU5qAfbcZHy9XddPqkxJNy8t2bsx0BkyCS2WHt5Xu+KXb AkNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=XWQo9luhHdVFPE4Rj01C3JoBhMnOD5GIOiP7elmdfMs=; b=CGFh023i6tudIAGMG/cRCfymcttt2+CuFXZzWf7LW41rgGaHEw3cqNjm9ATAUPl92+ 6lnKBpCLm7JIKfIqxBRSy8con/sqa5HOXriCG7KEz0AFRKmYLuJMh0jLCCs+qLxYOhkD 0pblNb2OVuJZb5S1S2vf42Ei3uHW0waNoB5THfrw42Hc41CDwOi6QvbUl5WSTYkd7loR 8kclFZ6htyMGGXrrJRFJ7OZFKOMYTQ9fItCiFWErKPF7I89m9/CSNiafRYSn46aNuLbs xuzQVH5Vpz6Vzk5ua8yA6c8BKQ04FE2ij2vebkrp3ZPUgIT6FTswtE9Y2/Rh8MAH//M/ lexQ== X-Gm-Message-State: AHQUAuaIZ690KLIbysajg2Lc6oqhzO6U843sIISTPUMa/rdlOWqUyhPv h2GCro7m62defBokkO7DzoTzlZbb5hh3NMr94OrQY/hB X-Google-Smtp-Source: AHgI3Ibtz+ppbTjRF+KGvljOYdtBCgmYZ6d7ZbLbhOYvv4VzNUMghnOvpBSIyr2u3VPAPNSjAn3kzXreP1RBUWall1Q= X-Received: by 2002:a6b:e802:: with SMTP id f2mr2741913ioh.296.1548324602787; Thu, 24 Jan 2019 02:10:02 -0800 (PST) MIME-Version: 1.0 Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Thu, 24 Jan 2019 05:09:45 -0500 Message-ID: To: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] How to handle block overflow in ChaCha-TLS? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 10:10:05 -0000 Hi Everyone, ChaCha-TLS from RFC 7539 uses one 32-bit word for a block counter. Bernstein ChaCha uses two words and we do something like this: if (++state[12] == 0) state[13]++; How do we handle the overflow in ChaCha-TLS? Do we throw an overflow exception? Do we carry into the 13th word (increment the high word of the nonce)? Do we wrap around (seems very bad)? Or something else? I'd also be grateful if someone knows where the official implementation of ChaCha-TLS is available to generate test cases. I'm particularly interested in starting the cipher with state[12] = 0xffffffff and see how it handles overflow when processing a large block. Jeff From nobody Thu Jan 24 10:00:43 2019 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 CC8221312D3 for ; Thu, 24 Jan 2019 10:00:41 -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 jGQ3-lslJk2E for ; Thu, 24 Jan 2019 10:00:39 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 797B61312CC for ; Thu, 24 Jan 2019 10:00:39 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id r24so2935838wmh.0 for ; Thu, 24 Jan 2019 10:00:39 -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=MiwK4GH1qfOaOyeH8qpYrH+LNLdnlXX8goOUhvRMx98=; b=cDXFpnG2jLaVn+ONP+gCs4RwClTJQNlHHy9VuGfAjK4Rq57YU2w2Nl/+M5QK7D3fBZ YuynYig+dBNOja1VLW4k3vov4xY8VK/F3t82aICIJa+/2nVOmwTaAWkgTTh9vvcvgBGi iKASq2xJjt/qhQRM89UIR3m/8htOcXhG3RrNyw/9nuhhEGn2S322QF204i9AiqftF3kn Vnke53G4CNVAJ/kqSgZ7j2HqAVJ29cdBzp96oane0KjA3K0wU5BA6nNbmeaty/L2u4to tkVNAkotr44uj0XcLaFZ3jcI7637/ZvDiIN+W2K/YOUw3ybUu5Kp6OMFQCCyiXfbaa7r bBrA== 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=MiwK4GH1qfOaOyeH8qpYrH+LNLdnlXX8goOUhvRMx98=; b=QEQ7QbknxiIIRXpxl4OzqbPfE500TRqbH5ApaWDVq6lHOv6hs+AbMUD8YXBFScmeC+ 7gqPDKrMM3054r8z7gbcDv+fyb0kM2eBOIumzxX3avu9Fh4I4fMpbGd9vSAJKLWMCyPV UaXMfUceFliZt1e+NolpGhh69TrSHIM0KSJu/3W1d0KNaQVYNmCJJEH3wb6sC42UI+F9 vMIVDw4vhSYezkGit6/L/ilbmC07hz4ZvNwxoGwC3OgwLSPcJibA+wO1m66cM7tyPKo4 oXswxvaQMh/HXNd2/zxsTr73lZMi4lHmx4Kt5rIjQQgHKoocfqadvTshUUum3y5WAY+l hArw== X-Gm-Message-State: AJcUukecKkivgOM0x3+b0Yd+VGRh3+TBHMC403lvizjlNv1ozc87NxUw uppriFfNWZ30k38ETBbgqvo/x2FA X-Google-Smtp-Source: ALg8bN7/luVImq6l8dC8Qxpd1K9jYokiCW+w1KbLMQGd0NVfg+JSxh4sm7cS1qnKJjSfSfqHAphfaw== X-Received: by 2002:a1c:90d5:: with SMTP id s204mr3666837wmd.148.1548352837606; Thu, 24 Jan 2019 10:00:37 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 67sm158306861wra.37.2019.01.24.10.00.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jan 2019 10:00:36 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5B8601AA-B1CA-4264-96E8-4D4B35C63CC8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 24 Jan 2019 20:00:34 +0200 In-Reply-To: Cc: Security Area Advisory Group To: noloader@gmail.com References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [saag] How to handle block overflow in ChaCha-TLS? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 18:00:42 -0000 --Apple-Mail=_5B8601AA-B1CA-4264-96E8-4D4B35C63CC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Jan 2019, at 12:09, Jeffrey Walton wrote: >=20 > Hi Everyone, >=20 > ChaCha-TLS from RFC 7539 uses one 32-bit word for a block counter. > Bernstein ChaCha uses two words and we do something like this: >=20 > if (++state[12] =3D=3D 0) > state[13]++; >=20 > How do we handle the overflow in ChaCha-TLS? Do we throw an overflow > exception? Do we carry into the 13th word (increment the high word of > the nonce)? Do we wrap around (seems very bad)? Or something else? >=20 > I'd also be grateful if someone knows where the official > implementation of ChaCha-TLS is available to generate test cases. I'm > particularly interested in starting the cipher with state[12] =3D > 0xffffffff and see how it handles overflow when processing a large > block. Hi, Jeff. ChaCha20-Poly1305 as described in RFC 7539 is intended for use in = network protocols such as TLS, IPsec, and SSH. All of those have packets = or records of reasonable length (65536 for IPsec, 16384 for TLS). A block of ChaCha20 is 64 bytes, so a TLS record requires at most 256 = blocks and an IPsec packet at most 1024. Both of these numbers easily = fit in a 32-bit block counter that is word 12. In theory, the modified = ChaCha20 can handle messages up to a million petabytes. For each new packet or record, you advance the nonce, which is in words = 13-15, allowing for up to 2^96 packets or records. The change we made allowed for more messages, but shorter ones, because = for the use of network protocols we figured that a limit of 2^38 bytes = per message was fine, but a limit of 2^64 messages per key was not. = More details about using this algorithm for TLS are available in RFC = 7905. And there=E2=80=99s no =E2=80=9Cofficial=E2=80=9D implementation. There = is one in OpenSSL as well as in many other libraries. I generated the = test vectors with a quick implementation that I wrote on this very = laptop that I=E2=80=99m using to send this message, but it was tested by = several other people with their own implementations prior to = publication. Hope this helps Yoav --Apple-Mail=_5B8601AA-B1CA-4264-96E8-4D4B35C63CC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24 Jan 2019, at 12:09, Jeffrey Walton <noloader@gmail.com> = wrote:

Hi Everyone,

ChaCha-TLS from RFC = 7539 uses one 32-bit word for a block counter.
Bernstein = ChaCha uses two words and we do something like this:

   if (++state[12] =3D=3D 0)
=        state[13]++;

How do we handle the overflow in ChaCha-TLS? Do we throw an = overflow
exception? Do we carry into the 13th word = (increment the high word of
the nonce)? Do we wrap around = (seems very bad)? Or something else?

I'd = also be grateful if someone knows where the official
implementation of ChaCha-TLS is available to generate test = cases. I'm
particularly interested in starting the cipher = with state[12] =3D
0xffffffff and see how it handles = overflow when processing a large
block.

Hi, = Jeff.

ChaCha20-Poly1305 as described = in RFC 7539 is intended for use in network protocols such as TLS, IPsec, = and SSH. All of those have packets or records of reasonable length = (65536 for IPsec, 16384 for TLS).

A = block of ChaCha20 is 64 bytes, so a TLS record requires at most 256 = blocks and an IPsec packet at most 1024.  Both of these numbers = easily fit in a 32-bit block counter that is word 12.  In theory, = the modified ChaCha20 can handle messages up to a million = petabytes.

For each new packet or = record, you advance the nonce, which is in words 13-15, allowing for up = to 2^96 packets or records.

The change we made allowed for = more messages, but shorter ones, because for the use of network = protocols we figured that a limit of 2^38 bytes per message was fine, = but a limit of 2^64 messages per key was not.  More details about = using this algorithm for TLS are available in RFC = 7905.

And there=E2=80=99s = no =E2=80=9Cofficial=E2=80=9D implementation. There is one in = OpenSSL as well as in many other libraries. I generated the test vectors = with a quick implementation that I wrote on this very laptop that I=E2=80=99= m using to send this message, but it was tested by several other people = with their own implementations prior to = publication.

Hope this = helps

Yoav



= --Apple-Mail=_5B8601AA-B1CA-4264-96E8-4D4B35C63CC8-- From nobody Fri Jan 25 19:52:13 2019 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 848B0131132 for ; Fri, 25 Jan 2019 19:52:11 -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 QySWpEBa5Olf for ; Fri, 25 Jan 2019 19:52:09 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 5A71E131131 for ; Fri, 25 Jan 2019 19:52:09 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id c9so12608956itj.1 for ; Fri, 25 Jan 2019 19:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=Df8SyrjU0CBoxdF8MSnC9jbeo5iXqxhW2hU4AaBX9wg=; b=atHnkv9lya3mwyY4WVAwPNmAF9um7Xan7+0cN4fO4ompvWZd8KlmB2Ud7oBFnwmkNx 5uBS+K8Inq9dsBBwE+xjT7RY+Jy4uqltJJ2u+hNSJooPnBRjhPp5lP5rb4RNVopSYn6g PTCM4CbU/0uaBMqvTYYB21Y+aqg/nPg8885N+KYP2HBvvpjhb+GsnnWaiN0kpAarYJuE aq9QF8WJlbLdMQ14HXGFPvMtN6f5BGAXeQgZAXX930PwpSAEm3THz/wYPTN/aWlbyi19 tKdEC4SUbQPg0cYjbhJ4TPdyXJW1cZr1nej3yb6H7qkt59OJ0zsnWGvo3j3x6kmJ0OHy nBMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=Df8SyrjU0CBoxdF8MSnC9jbeo5iXqxhW2hU4AaBX9wg=; b=A+SdmHt7/DDaBewR3N95p9mClb/cXwz5F3C7/NoChNQPPu/fyxWc63ARLWr7LCpAE4 J9v8YpS0NYlBKzLrN9PFZ4EAn1eAlLg9fvuN+sfFjiTOLJBOXJZdtLxBD70HpZ0kKSng REwk5W3oTH5BpZt3w8zlhBHoejNRDxbU/tyAbaSdbBSO587eXRy+rxYnylRSNnU+kqvd DXn5Ws8GCDht5sqXFrvG8cPsfEXLI+QNxIpt5lBmM6XDqt8hMv/GSf3PwHFo7GYgQmR7 FAuXhnEcvSYGVKkEdXzgCxZkmF9BeEFF+pFz2PVdhNNozCnnz47ryfMIXvvBR8E1N09w N9OQ== X-Gm-Message-State: AJcUukeHKTs0BfB5HO1IROkAU6Hu86qYtOaHoEhMQ1oglgplKRJ9DgJv oKA52iKGhZb3h7XPi9OdKja59hpEoLLNMdmrgDB1Znqj X-Google-Smtp-Source: ALg8bN5RqbAiasEmzWjXsZ97yi73HylsBtaPy1BnZcsmOsk3axj8CsAW27QzuWZN6N0oxZVQCQhCn6nDN+L2L3m39tM= X-Received: by 2002:a24:67c2:: with SMTP id u185mr6028601itc.171.1548474728318; Fri, 25 Jan 2019 19:52:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Fri, 25 Jan 2019 22:51:46 -0500 Message-ID: To: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] How to handle block overflow in ChaCha-TLS? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2019 03:52:12 -0000 On Thu, Jan 24, 2019 at 5:09 AM Jeffrey Walton wrote: > > ChaCha-TLS from RFC 7539 uses one 32-bit word for a block counter. > Bernstein ChaCha uses two words and we do something like this: > > if (++state[12] == 0) > state[13]++; > > How do we handle the overflow in ChaCha-TLS? Do we throw an overflow > exception? Do we carry into the 13th word (increment the high word of > the nonce)? Do we wrap around (seems very bad)? Or something else? The question was moved to the CFRG list at How to handle block counter wrap in IETF's ChaCha algorithm?, https://mailarchive.ietf.org/arch/msg/cfrg/gsOnTJzcbgG6OqD8Sc0GO5aR_tU. Jeff From nobody Sun Jan 27 04:45:37 2019 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 0A20812F19D; Sun, 27 Jan 2019 04:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 fOxO23IbqcOH; Sun, 27 Jan 2019 04:45:31 -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 CC4B512D4EF; Sun, 27 Jan 2019 04:45:29 -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=1548593131; x=1580129131; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sUVqhGggChymaZuvZD33F+iMzBjL09qqG1JS2uJOvuA=; b=REcL77ZoxZ+h7YSMmyd8dEO1duo7tZNCbQQTiACLw1j2LLcy7CrWzTn0 IMS+Fa9wR8iz4xGC/DB/OjY5Qy51YZo7Ky6nZCk3nOLmh2mJZATVa1qzo VLMXxZ/zApQ+NaUf2hh5bMBdWMUc43igSSBVjmDhjh6e9uwjDR52Gnsxl wVHd5bJkTdu/YTEMbVbYH1pag2Gy5ftdY0QQduLqnibnQeJWZvGILHEES QIUSNXepiAQvojVjr6njhbV4K8Z2o8j59iGbPZE++4Mgylc4vsIxGZlGc TUAYx6/xfRse8YbBiX2xSajxTvh/euE6IPhSmex3Tzs30Ig1IauLKAvgl w==; X-IronPort-AV: E=Sophos;i="5.56,529,1539601200"; d="scan'208";a="46554093" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Jan 2019 01:45:27 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 28 Jan 2019 01:45:26 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 28 Jan 2019 01:45:26 +1300 From: Peter Gutmann To: Alexey Melnikov CC: "draft-gutmann-scep@ietf.org" , "carl@redhoundsoftware.com" , "saag@ietf.org" Thread-Topic: [saag] Comment added to draft-gutmann-scep history Thread-Index: AQHTx0JalykNlRFNLEeHWmw80fOk66PxVi1qgCgcEDyAL8YogIBEQ8VngSI/joCADi2UO///uv+AgAdIx28= Date: Sun, 27 Jan 2019 12:45:26 +0000 Message-ID: <1548593086641.10465@cs.auckland.ac.nz> References: <152231658869.24008.11321959845877039592.idtracker@ietfa.amsl.com> <1522887334433.4490@cs.auckland.ac.nz> <1525092187804.38190@cs.auckland.ac.nz> <1531471734017.88813@cs.auckland.ac.nz> <1548207354255.65634@cs.auckland.ac.nz>, 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] Comment added to draft-gutmann-scep history X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2019 12:45:35 -0000 OK, just posted it with (hopefully) all changes as requested, one small=0A= difference is that I've put the HTTP note in section 4 which talks about HT= TP=0A= use:=0A= =0A= This section describes the SCEP Transactions and their HTTP [6] transpor= t=0A= mechanism.=0A= =0A= where it's more likely to be noticed than if it's tacked onto the=0A= introduction. I've also extended it a bit to point to the upcoming BCP-56,= =0A= which contains a lot of good advice on use of HTTP as a substrate:=0A= =0A= -- Snip --=0A= =0A= Note that SCEP doesn't follow best current practices on usage of HTTP. In= =0A= particular, it uses unregistered Media Types, it recommends ignoring Media= =0A= Types and hardcoding specific URI paths. Guidance on the appropriate=0A= application of HTTP in these circumstances may be found in=0A= =0A= REF: "Building Protocols with HTTP", draft-ietf-httpbis-bcp56bis-08, Mark= =0A= Nottingham, November 2018,=0A= https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08.=0A= =0A= -- Snip --=0A= =0A= Before the final version is published I'll go through it one more time to= =0A= align it with draft-BCP-56bis as much as possible, mostly a reference to=0A= section 4.5.1 on the use of GET vs POST.=0A= =0A= Peter.=0A= From nobody Mon Jan 28 04:11:57 2019 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 85CB2131027; Mon, 28 Jan 2019 04:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 g8qcedf5N5qI; Mon, 28 Jan 2019 04:11:54 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id D675113100D; Mon, 28 Jan 2019 04:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1548677513; d=isode.com; s=june2016; i=@isode.com; bh=1T/QX+Fystwenc1ZMmA6if/HBHZHvc/LQ173mgI3HLE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HvThLjmoPcfEcbz3IOLwalpbaTLmh1swSGPkCw51+/NlL7cDnXKoy8DhA5K3bLVSQFDfbE +eOIZn5lJfLONelAPFhaME6IQ2SrdaQ44f2Es6hP6a7k2jrLwwNODX/b9hSrHeSncUAlXN aUJV4HMDmU0KQT8Q4PR4dtUJen61QqU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 28 Jan 2019 12:11:52 +0000 To: Peter Gutmann Cc: "draft-gutmann-scep@ietf.org" , "carl@redhoundsoftware.com" , "saag@ietf.org" References: <152231658869.24008.11321959845877039592.idtracker@ietfa.amsl.com> <1522887334433.4490@cs.auckland.ac.nz> <1525092187804.38190@cs.auckland.ac.nz> <1531471734017.88813@cs.auckland.ac.nz> <1548207354255.65634@cs.auckland.ac.nz> <1548593086641.10465@cs.auckland.ac.nz> From: Alexey Melnikov Message-ID: Date: Mon, 28 Jan 2019 12:11:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <1548593086641.10465@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [saag] Comment added to draft-gutmann-scep history X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 12:11:56 -0000 Hi Peter, On 27/01/2019 12:45, Peter Gutmann wrote: > OK, just posted it with (hopefully) all changes as requested, one small > difference is that I've put the HTTP note in section 4 which talks about HTTP > use: > > This section describes the SCEP Transactions and their HTTP [6] transport > mechanism. > > where it's more likely to be noticed than if it's tacked onto the > introduction. I've also extended it a bit to point to the upcoming BCP-56, > which contains a lot of good advice on use of HTTP as a substrate: > > -- Snip -- > > Note that SCEP doesn't follow best current practices on usage of HTTP. In > particular, it uses unregistered Media Types, it recommends ignoring Media > Types and hardcoding specific URI paths. Guidance on the appropriate > application of HTTP in these circumstances may be found in > > REF: "Building Protocols with HTTP", draft-ietf-httpbis-bcp56bis-08, Mark > Nottingham, November 2018, > https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08. > > -- Snip -- That would be fine. Please post a new revision that includes this text. > Before the final version is published I'll go through it one more time to > align it with draft-BCP-56bis as much as possible, mostly a reference to > section 4.5.1 on the use of GET vs POST. Ok. Best Regards, Alexey From nobody Mon Jan 28 15:02:32 2019 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 DE1071310DE; Mon, 28 Jan 2019 15:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 FhOCwsTC1lLF; Mon, 28 Jan 2019 15:02:28 -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 6108C130EE4; Mon, 28 Jan 2019 15:02:27 -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=1548716547; x=1580252547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rTIAK8NNI0cObHPvDUtreC2EekVzv47g9aRkn6+MnMk=; b=SUCyupiVLEkRENa/bZblRUaxpcH76es4E3XboBpcsfROS+9j7Fa/ZddO W/HvboMUVHcCgXDhMRkQVTTXNDBmir0XFB9Qu+f1+NrKFqW0hfxCh0WEt R+eavbHuLDm5izLTjprsAyXtEjlCTuTz+XnUzkNfcCM+h0UOuW0dD26Qg nO4qiIMxRqVljUaHnXDB4qcHMdoDLGxxQJg5U9mI8dPxVXiA2pMZ7Nzv7 Vr9YHarT/cSsVu62tp4J/STBh+MDKuicusnQ5IJvKEUqwPYWic/WUMHoU T7v3w4EjTgCiAZuZjDNRnkdPlAcuuOWbhttP2tJthuemXfrMNlHDdZQQ5 Q==; X-IronPort-AV: E=Sophos;i="5.56,535,1539601200"; d="scan'208";a="46671456" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jan 2019 12:02:23 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 29 Jan 2019 12:02:23 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 29 Jan 2019 12:02:23 +1300 From: Peter Gutmann To: Alexey Melnikov CC: "draft-gutmann-scep@ietf.org" , "carl@redhoundsoftware.com" , "saag@ietf.org" Thread-Topic: [saag] Comment added to draft-gutmann-scep history Thread-Index: AQHTx0JalykNlRFNLEeHWmw80fOk66PxVi1qgCgcEDyAL8YogIBEQ8VngSI/joCADi2UO///uv+AgAdIx2+AAK/EAIABj3d3 Date: Mon, 28 Jan 2019 23:02:22 +0000 Message-ID: <1548716500325.50962@cs.auckland.ac.nz> References: <152231658869.24008.11321959845877039592.idtracker@ietfa.amsl.com> <1522887334433.4490@cs.auckland.ac.nz> <1525092187804.38190@cs.auckland.ac.nz> <1531471734017.88813@cs.auckland.ac.nz> <1548207354255.65634@cs.auckland.ac.nz> <1548593086641.10465@cs.auckland.ac.nz>, 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] Comment added to draft-gutmann-scep history X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 23:02:31 -0000 Alexey Melnikov writes:=0A= =0A= >That would be fine. Please post a new revision that includes this text.=0A= =0A= Argh, sorry, that should have already been in there but I didn't copy the t= ext=0A= across after writing it up in the email message. Fixed now in -13:=0A= =0A= 4. SCEP Transactions=0A= =0A= This section describes the SCEP Transactions and their HTTP [7]=0A= transport mechanism.=0A= =0A= Note that SCEP doesn't follow best current practices on usage of=0A= HTTP. In particular, it uses unregistered Media Types, it recommends=0A= ignoring Media Types, and hardcodes specific URI paths. Guidance on=0A= the appropriate application of HTTP in these circumstances may be=0A= found in [12].=0A= =0A= Peter.=0A=