From nobody Fri Dec 6 15:28: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 18C8A1200F6 for ; Fri, 6 Dec 2019 15:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Phh9w9SJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Rxbub97X 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 M13mubOUw2As for ; Fri, 6 Dec 2019 15:28:02 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1DD120073 for ; Fri, 6 Dec 2019 15:28:02 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 669B622959 for ; Fri, 6 Dec 2019 18:28:01 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 06 Dec 2019 18:28:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:mime-version:subject:message-id:references:to :date; s=fm1; bh=ekpPYggKxl/XuPZJOgej02l01ZpKSNSC6msz8Cq030Q=; b= Phh9w9SJYme/eNBw8nPSWeTBDDdMWOLzpTbywYPf07yUqMya8Gzj6xWUYjSsiWfm xXzsJaQEy4Lrzre+SF5LG1V3xo3h5BHL2M+9db277/xrx53zTNnt2XuFil8dT01L jpJiwp9nOIMZwXvE1rxFXlALdLga+EcHHP8aAwbJ2VfrA1qtUGmXXjRp6shG30oS lv11jp6m6d8y1oTchY5YNy903wLjPjLeT+mPOTjAlKHYP8UdZCWZyy7CXVTKNHI5 lNPa3IL2GL0RsHXrEAzDp4snyZvpUtBTyuccf1je3JAgQxfX2j19BO6tdeTWvuVp h4wDl13/Ci6SN5wJIZCb8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ekpPYggKxl/XuPZJO gej02l01ZpKSNSC6msz8Cq030Q=; b=Rxbub97XhiGnHbV7zP1e24zqyxzidXOhT WE5S8zMVg6LNcDCEiS8AoRssh0L4SleCWf5mbFiOQrloZTALM5litfhSREd9Q6I6 xGRBWljTdNA4DXY4lV+Mx7uUbtpmTzBEnbTQJMKlaJSwLGiOGBOvezjkEI8y6ljh 6PNyybE5y+ZjhdsPfIEB1OUtI8ksyHhlhDfSBkzPktHjDf/gc12t57dyeFWfHAia x7m+EKG6BOEtSABoH2jrEO/7tETsMVEulg14CbmqyfuhKnnUEDpmIQ8kqdCwyo93 efe5f+0SMqo+wTCjuMe5/xdLmx0ZEfjxxgiIaYE0O8sIAMQ3/DBgg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekgedgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtggguffkfhfvfffosegrtdhmre hhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhho thdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgpd hmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecurfgrrhgrmhep mhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 5CBE330600B0 for ; Fri, 6 Dec 2019 18:28:00 -0500 (EST) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_CC9B89EB-98A6-4D07-8F9C-F1E8B95C2F6E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <7E07F702-BEF5-4C4C-B952-8E382B7074D8@mnot.net> References: <157403781873.6404.6154827441040413193.idtracker@ietfa.amsl.com> To: saag@ietf.org Date: Sat, 7 Dec 2019 10:27:59 +1100 X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [saag] Fwd: New Version Notification for draft-iab-for-the-users-01.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: Fri, 06 Dec 2019 23:28:05 -0000 --Apple-Mail=_CC9B89EB-98A6-4D07-8F9C-F1E8B95C2F6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The IAB wanted to give this draft wider exposure to folks than just = those on architecture-discuss; comment / feedback welcome (here, or on = the draft issues list at = >). Apologies if you've seen this before. Cheers, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-iab-for-the-users-01.txt > Date: 18 November 2019 at 11:43:38 am AEDT > To: "Mark Nottingham" > >=20 >=20 > A new version of I-D, draft-iab-for-the-users-01.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-iab-for-the-users > Revision: 01 > Title: The Internet is for End Users > Document date: 2019-11-18 > Group: iab > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-iab-for-the-users-01.txt = > Status: = https://datatracker.ietf.org/doc/draft-iab-for-the-users/ = > Htmlized: https://tools.ietf.org/html/draft-iab-for-the-users-01 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-iab-for-the-users = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-for-the-users-01 = >=20 > Abstract: > This document explains why the IAB believes the IETF should consider > end users as its highest priority concern, and how that can be done. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_CC9B89EB-98A6-4D07-8F9C-F1E8B95C2F6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The IAB wanted to give = this draft wider exposure to folks than just those on = architecture-discuss; comment / feedback welcome (here, or on the draft = issues list at <https://github.com/intarchboard/for-the-users/issues>).<= div class=3D"">
Apologies if you've = seen this before.

Cheers,


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-iab-for-the-users-01.txt
Date: = 18 November 2019 at 11:43:38 am = AEDT
To: = "Mark Nottingham" <mnot@mnot.net>

A new version of I-D, draft-iab-for-the-users-01.txt
has been successfully submitted by Mark Nottingham and posted = to the
IETF repository.

Name: = = draft-iab-for-the-users
Revision: 01
Title:= = The Internet is for End Users
Document date: = 2019-11-18
Group: iab
Pages: 11
URL: =            https://www.ietf.org/internet-drafts/draft-iab-for-the-users-01= .txt
Status: =         https://datatracker.ietf.org/doc/draft-iab-for-the-users/Htmlized:       https://tools.ietf.org/html/draft-iab-for-the-users-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-iab-for-the-users
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-for-the-users-01<= /a>

Abstract:
=   This document explains why the IAB believes the IETF should = consider
  end users as its highest priority = concern, and how that can be done.




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


--
Mark = Nottingham   https://www.mnot.net/

= --Apple-Mail=_CC9B89EB-98A6-4D07-8F9C-F1E8B95C2F6E-- From nobody Mon Dec 9 13:53:50 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 8C5E31200C5 for ; Mon, 9 Dec 2019 13:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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 wI3G-uIS3uR5 for ; Mon, 9 Dec 2019 13:53:46 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 DF146120086 for ; Mon, 9 Dec 2019 13:53:45 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id g4so6448091pjs.10 for ; Mon, 09 Dec 2019 13:53:45 -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=Qa8pRK71b96CW64UFatNA4rnXecCxAw54GFGNESxbqE=; b=qgxXIiZZ9MdMXKvI1yPry3WVXv+f9E73Rt29n1qs9jisagl5HeoOixodPKDwDRouzo 4dLM4LBNQqOv/Vps9+1URSZ12I64YNnidNzXAaCYtOKbcKkfn4LUcbMtD8NlHCsRwk/6 jzftlsWeq9RAywunLNBA+O64Q2G7NZdKM9Wux7r6iLyfRj3470Zh5y2oxzhJsovMiicb 3Q32k3FOvehV8U47P36Jhuwu1gJifRT1Edi6i2LjcsODncMi9qtuavYoq7JSN3KaSZc/ F045L7r2ds8Qqt5oLm4wXF4H8KTZ3Y5Idw0bqRSpqbimtTq0Mk50g2027+soVT1S15UR OK+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Qa8pRK71b96CW64UFatNA4rnXecCxAw54GFGNESxbqE=; b=QTsx7Mc/NuolX8haMxlSQFXvxDBS7kET/+wvFymIh/iTvQp0VKKOjB35vJdshQQerN FZHnlzX42vgaU01RL40AVQ0UHWEd9eGRBwPG6wOHLYhhopgjx5scnc+k8DtcZNOYCwr4 7BjEQpC/Eg78mqiqctUXQbLEik2NV8U3/DqdCM54EN2b7GiBwgzvtHld3eTGcWFC2hEs KEv8oi5tiVmTRziQhgZV3/bw5o6tmzBIi9KyN0bbBMy225smnU5LYWHWb5ux3fcsiRFp nAyd/SG0SQX4quZZH1t/aRkgVyZamsc/vGfVgWhG6v4nfrnR2Hma2r0wSS/DoF2DC3/2 F4tA== X-Gm-Message-State: APjAAAXdNoP+40zeCR3B4lPXUt8CMFfw6F0SQPY+FUh2teWnMMwroC9D Y7Pq4jzHN8gGSRBWvPaWXH4e/t2K9OjK/8aKcBwqsG/uNClNMQ== X-Google-Smtp-Source: APXvYqwNajbfDqwpiCtVPTvEjWbpYWAnY6w/9yFtO4qgYbHy99mWcN4zHtp6I11PQmxDHTR23HnrATE32qVTR5mgkc0= X-Received: by 2002:a17:902:bcc8:: with SMTP id o8mr31447552pls.81.1575928425003; Mon, 09 Dec 2019 13:53:45 -0800 (PST) MIME-Version: 1.0 References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> In-Reply-To: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> From: Yakov Shafranovich Date: Mon, 9 Dec 2019 16:53:09 -0500 Message-ID: To: Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Fwd: Last Call: (A Method for Web Security Policies) to Informational RFC 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, 09 Dec 2019 21:53:48 -0000 ---------- Forwarded message --------- From: The IESG Date: Mon, Dec 9, 2019 at 12:39 PM Subject: Last Call: (A Method for Web Security Policies) to Informational RFC To: IETF-Announce Cc: , , The IESG has received a request from an individual submitter to consider the following document: - 'A Method for Web Security Policies' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-01-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Dec 14 12:21: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 EE137120822 for ; Thu, 12 Dec 2019 19:00:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.au.dk 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 XiUObusi4vWC for ; Thu, 12 Dec 2019 19:00:07 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50046.outbound.protection.outlook.com [40.107.5.46]) (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 E021F120820 for ; Thu, 12 Dec 2019 19:00:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nwfSAjmycEVGlw3BBTONHCffjKEn/Jo0FzTmJhTydwiSqWtbreGHFnUh4QyI/GjSU0rxtF0VYYSGMEAur5z2BDU24MfSvGCAlbm0vLg01I9bY+OzlSaVCQpgwgMQOn+8pO/Izbt9OA7Rz5hWVrJpfsrtwz1Y6f85MHqihx68I0znCxc5Lk8XvenYywOoWSDVDFtdscuQU0eZOkUmdUaLQOg1tjDrgyJWsAKrCaFFb2V5rDI2MRVHukzB/FcNT1BEKnSv0rLJO6AEBYcnVlRPFoDxIGMTp5UTIpG9cewNEso25mXmCzgUygKHfhhuqLXg2C76F0pPGcFel4qjV+jtsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ps2GneqyI92QrrHDV/eBrRiZjzjMZYY97eau1rEbSo=; b=V6stLA9vwQoEnximxLIwkm2Y/QFB0TjNsEe4OBG6Nl8DvQZYYApGHFWHy9qEE/hUskamYLqgZ6MnhVg52VCpjTUPrvMCYdyl/Vy3i0lKWtgeRHM8oKGxKVcunRuIxj+nJY+c6w/qCvpBO0BaSZFUjD+94zpR7ekXR+iykfkNA+UBA1cbPwdGI2jbP17CY5+7kTIBB7lj03QNeNbZfV0WChor2yVWm7qCsOW364e0CUS9uNzUOC1sp/cB/qpaWc9MjPyNaFvKFQoX57UM/z4BsR8yBorkTQt6i3tjA8PtIXvpgemvaBKCUorQLB8Pr2QnyLCaJa9XWwl9oCsQsNOieA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.au.dk; dmarc=pass action=none header.from=cs.au.dk; dkim=pass header.d=cs.au.dk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.au.dk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ps2GneqyI92QrrHDV/eBrRiZjzjMZYY97eau1rEbSo=; b=hsBItB3iSZ++kk4q/qFv9Ll087MWbGzu85CuJ8YV0iUKX2eR2UsXduL6gNAfuP6n3/4CpQpRrZ/gjQtEZRkOOGk4rHQSIYj73qpSAnKLEQcY/7g/G7bWdIlfPM28DXUkiY1T8gY0Xb6jFQUeDLKBSq59Cktgslr8Z37oF/VT88w= Received: from DB6PR0102MB2838.eurprd01.prod.exchangelabs.com (10.170.214.149) by DB6PR0102MB2696.eurprd01.prod.exchangelabs.com (10.170.210.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.17; Fri, 13 Dec 2019 03:00:02 +0000 Received: from DB6PR0102MB2838.eurprd01.prod.exchangelabs.com ([fe80::8886:77a9:c9bf:7b38]) by DB6PR0102MB2838.eurprd01.prod.exchangelabs.com ([fe80::8886:77a9:c9bf:7b38%7]) with mapi id 15.20.2516.019; Fri, 13 Dec 2019 03:00:02 +0000 From: Akira Takahashi To: John Mattsson , "cfrg@irtf.org" , "saag@ietf.org" , "Diego F. Aranha" , Claudio Orlandi , Greg Zaverucha Thread-Topic: [Cfrg] Recommendations Regarding Deterministic Signatures Thread-Index: AQHVsWFoT88TcBJjaEuKXvLQCyOcEQ== Date: Fri, 13 Dec 2019 03:00:01 +0000 Message-ID: References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=takahashi@cs.au.dk; x-originating-ip: [210.149.252.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a39af628-e422-4183-9599-08d77f788c3b x-ms-traffictypediagnostic: DB6PR0102MB2696: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0250B840C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(366004)(376002)(396003)(199004)(189003)(53546011)(316002)(5660300002)(52536014)(86362001)(966005)(81166006)(55236004)(6506007)(4744005)(786003)(71200400001)(186003)(66946007)(76116006)(26005)(66556008)(33656002)(2906002)(8676002)(64756008)(55016002)(66476007)(66446008)(7696005)(8936002)(110136005)(9686003)(91956017)(81156014)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0102MB2696; H:DB6PR0102MB2838.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cs.au.dk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BWv7IGFsZrvMkANZtgw9xVuDGMlNiw4yer6N7n/+3uy8OZHXhbnW/yxf08QHU0ohVDFOXB0nncjCwI7AkdzhVxEwWPXBUV8k2hpsh/DknFx2mIR+jEcxRU5UGFWpHinCrTq0ytq7/o1/wMXC4+jL/RDBMccJcKHPjCuqsJ6AaxpH5YdtvE/qLk/XauensHU1sTAAzoKcXCEECQ6cpeeB7PVSxr4jwL1rmG1rC72GNICFZNyPNzTrpZjNECH0bv+GwXSSv68PvZM5Yn/t/kSlfzF9EYgqzy+vLFzDIHSbT5MdMhLnK+NCHAivuilB+Hh0ynYzVlX293LL/4Lk+xGn8k174SVf9s17gzxG7EnUXuImc/K7S2/NkUPrUv3m+wHRW+weBuPcFaKwSR07Z7cjvBXPRDZtaLQxFWn+Cvb/BX+wzzh5JJ/vC/lo5Xobkr2KQwEdtrC+LDndFT4/EDsGzakDYuHfzw0rJXZMDDhIcng= Content-Type: multipart/alternative; boundary="_000_DB6PR0102MB283861277B9ADF9D1A7551A395540DB6PR0102MB2838_" MIME-Version: 1.0 X-OriginatorOrg: cs.au.dk X-MS-Exchange-CrossTenant-Network-Message-Id: a39af628-e422-4183-9599-08d77f788c3b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 03:00:02.0033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 61fd1d36-fecb-47ca-b7d7-d0df0370a198 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MMAgZ2HNdlzbfKIZqJg5dlbPoEy6a9NBBDUdh1oyJAATxAgB9gjuSsWlYPn6dVzbUiMszUpO5Ugq4aM4+2glkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0102MB2696 Archived-At: X-Mailman-Approved-At: Sat, 14 Dec 2019 12:21:12 -0800 Subject: Re: [saag] [Cfrg] Recommendations Regarding Deterministic Signatures 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: Fri, 13 Dec 2019 03:00:10 -0000 --_000_DB6PR0102MB283861277B9ADF9D1A7551A395540DB6PR0102MB2838_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 11/27/19 12:13 PM, John Mattsson wrote: My current view is that best practice seems to be to use deterministic algo= rithms (deterministic ECDSA or EdDSA) with "additional randomness" / "noise= " like in XEdDSA. This also mitigates attacks on theoretical use cases wher= e deterministically signing the same message twice leaks information. We would like to draw your attention to our recent result related to such "= hedged" constructions that derive the randomness by hashing the secret key,= message, and a nonce: D. F. Aranha, C. Orlandi, A. Takahashi, G. Zaverucha. Security of Hedge= d Fiat=96Shamir Signatures under Fault Attacks. 2019. https://eprint.iacr.o= rg/2019/956.pdf We analyzed the fault resilience of hedged Fiat-Shamir type signatures with= in the provable security methodology and formally confirmed that the counte= rmeasure does thwart several recent attacks targeted at the deterministic o= nes. Our result also directly applies to XEdDSA. Best regards, Diego, Claudio, Akira, and Greg --_000_DB6PR0102MB283861277B9ADF9D1A7551A395540DB6PR0102MB2838_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 11/27/19 12:13 PM, John Mattsson wrote:
My current view is that best practic=
e seems to be to use deterministic algorithms (deterministic ECDSA or EdDSA=
) with "additional randomness" / "noise" like in XEdDSA=
. This also mitigates attacks on theoretical use cases where deterministica=
lly signing the same message twice leaks information.=0A=
We would like to draw your attention to our recent result related to such &= quot;hedged" constructions that derive the randomness by hashing the s= ecret key, message, and a nonce:

    D. F. Aranha, C. Orlandi, A. Takahashi, G. Zaverucha. Se= curity of Hedged Fiat=96Shamir Signatures under Fault Attacks. 2019. https://eprint.iacr.org/2019/956.pdf

We analyzed the fault resilience of hedged Fiat-Shamir type signatures within th= e provable security methodology and formally confirmed that the countermeas= ure does thwart several recent attacks targeted at the deterministic ones.<= br> Our result also directly applies to XEdDSA.

Best regards,
Diego, Claudio, Akira, and Greg --_000_DB6PR0102MB283861277B9ADF9D1A7551A395540DB6PR0102MB2838_-- From nobody Fri Dec 20 07:19:39 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 EF34F12009E for ; Fri, 20 Dec 2019 07:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 opkQGgiVWfNF for ; Fri, 20 Dec 2019 07:19:36 -0800 (PST) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 A3A261200B1 for ; Fri, 20 Dec 2019 07:19:36 -0800 (PST) Received: by mail-oi1-f179.google.com with SMTP id c16so4697412oic.3 for ; Fri, 20 Dec 2019 07:19:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ww0oAjoWacUOQQlKiK7jCE8bBexeE1O/h8m1K1mB2Z4=; b=Ac1FXC5hw1XI5Y3vcvmoW+g9qexRzzpMw/g2pKWgaZn4VMpBfbOui7wm/8b2uCptl0 OmNBIILXG09prPz06wECTTKZcRzh5q6S8hlzESiAzeUEt38j1Zf+B+GzftD0bkFsxaAq q8RJ3n3HCPLjrqr05DNdnczBukvp4LGWfD6Q5vAJRsCSDiu+QlKyaiH6KD5Zhz6813qU cskQ5lljbXrehf8MLg3GXQkPRC3XVerSJCr9JkGNzmtM1K3yziO92HJtqVm57sBkB3RH ROz8pXEbM9muipiKahTl1nAas9SJDDQe8KeeaTzrbYBL9dEb1N002hNW2VzDlDagT0uC +SMQ== X-Gm-Message-State: APjAAAUdLpB2akfiNaaIwX/7vpmmM0c6z8vWgRQyOcJonpJcPnVoTtGG J29LLkosQI3ivHPY5UXOQ5rXFzPnBG+edoMxYARzvJXQN4Q= X-Google-Smtp-Source: APXvYqyPEtc5JW1nRwi3BbjTtMcH5roZL5SxBafnPabAzXrG6BPw2QBZXuytEEgmrqkNcASamEUIL4KP1vjDX+SAac0= X-Received: by 2002:aca:cdd6:: with SMTP id d205mr3877356oig.90.1576855175598; Fri, 20 Dec 2019 07:19:35 -0800 (PST) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Fri, 20 Dec 2019 10:19:24 -0500 Message-ID: To: IETF SAAG , cfrg@irtf.org Content-Type: multipart/alternative; boundary="0000000000009a973b059a2434d0" Archived-At: Subject: [saag] US Patent 6,327,661 is 20 years old 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: Fri, 20 Dec 2019 15:19:38 -0000 --0000000000009a973b059a2434d0 Content-Type: text/plain; charset="UTF-8" US Patent 6,327,661: Using unpredictable information to minimize leakage from smartcards and other cryptosystems was filed in June 1999. It is therefore more than 20 years old which usually means it has expired. http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F6327661 This is a particularly important patent as it covers use of randomization to prevent the Fourier side channel attacks Paul Kocher is known for (he is the inventor). There are some extensions of the scheme that are covered by patents still in force (e.g. US10181944B2 but that one is of extreme specificity and clearly intended to keep a lock on a particular standard). I believe that it is very important that we begin using these techniques because Montgomery Ladders are not sufficient to provide protection against timing attacks so X25519/X448 are rather more vulnerable to side channel attack than people would like to admit and Ed25519/Ed448 are not protected at all. The Mesh uses similar math and as of ten minutes ago, the code for the X25519/X448 implementation passes its unit tests. My current plan is to separate this work from the rest of the Mesh and propose it to CFRG. If there is IETF work on the Mesh, the crypto parts are going to be sent there for consideration in any case. It is my understanding (see disclaimer) that this means that there is prior art for all the essential technologies used in the Mesh. Provisional patent applications were filed on certain parts of the Mesh technology but these have been abandoned with the exception of one application describing a non essential technology that the IETF has decided not to pursue in any case (US Patent Application 20190036892). Disclaimer: This is not legal advice, no warranties, all parties are responsible for performing due diligence etc. --0000000000009a973b059a2434d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
US = Patent 6,327,661: Using unpredictable information to minimize leakage from = smartcards and other cryptosystems was filed in June 1999. It is therefore = more than 20 years old which usually means it has expired.

http://patft.uspto.gov/netacgi/nph= -Parser?Sect2=3DPTO1&Sect2=3DHITOFF&p=3D1&u=3D%2Fnetahtml%2FPTO= %2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&d=3DPALL&RefSrch= =3Dyes&Query=3DPN%2F6327661=C2=A0=C2=A0

This is a particularly=C2=A0important patent as = it covers use of randomization to prevent the Fourier side channel attacks = Paul Kocher is known for (he is the inventor).

There are some extensions of the scheme that are cove= red by patents still in force (e.g. US10181944B2 but that one is of extreme= specificity and clearly intended to keep a lock on a particular standard).=

I believe that it is ver= y important that we begin using these techniques because Montgomery Ladders= are not sufficient to provide protection against timing attacks so X25519/= X448 are rather more vulnerable to side channel attack than people would li= ke to admit and Ed25519/Ed448 are not protected at all.

The Mesh uses similar math and as of ten min= utes ago, the code for the X25519/X448 implementation passes its unit tests= . My current plan is to separate this work from the rest of the Mesh and pr= opose it to CFRG. If there is IETF work on the Mesh, the crypto parts are g= oing to be sent there for consideration in any case.

It is my understanding (see disclaimer) that th= is means that there is prior art for all the essential technologies used in= the Mesh. Provisional patent applications were filed on certain parts of t= he Mesh technology but these have been abandoned with the exception of one = application describing a non essential technology that the IETF has decided= not to pursue in any case (US Patent Application 20190036892).

Disclaimer: This is not legal advice= , no warranties, all parties are responsible for performing due diligence e= tc.=C2=A0

<= /div>

--0000000000009a973b059a2434d0-- From nobody Fri Dec 20 10:09:19 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 7F1CF12087A for ; Fri, 20 Dec 2019 10:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 mXTCed-8lRoV for ; Fri, 20 Dec 2019 10:09:16 -0800 (PST) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (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 7BAC012084D for ; Fri, 20 Dec 2019 10:09:16 -0800 (PST) Received: by mail-oi1-f180.google.com with SMTP id l9so2365295oii.5 for ; Fri, 20 Dec 2019 10:09:16 -0800 (PST) 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=31TcMeZ77YxuxkmTovzh42BsEoRQOh+lV+z5lLCvNSw=; b=swgAujgt8KqdqqLtzo9kUCde6ZGa1vL0RPB78v9EOdlhIzPN1HRmEM/bvH95aVrwXX kegpHTHamRf++BHD0K/yP6GnxVbAkTemUtbkZtlDZxcJsMtVcdGI3KHCk4aXPeuDq7Jd RedrKsHrfG5qMR7RHm0zZT2Llpsjrt4y3L4hh706NosHQS5zeuY7bU3OpW4Vo98Vk7ix Wu/EGrONvh58OxqXQDM4HiZdDU2dJYgKtYoNvAjawkdMw6KUG2UYfuTcRID9b8O9gn7k XwEChyYXtMOkKIDF78aqsBdBIQ04YmjqtthwwlP6eIqvNZL6eetDXq/jMUqdPFwwKjwu Sd0w== X-Gm-Message-State: APjAAAVdS8RV3+JL/pct4MEeFK8j1gsniCERnHFyaJM78Wbi9l6yrrcf uhk/hzLa94Wi+leplAxD/pq9lQUTFxK0jqbVwBg= X-Google-Smtp-Source: APXvYqw0Qa//IK5Fw3KkuGWEQFhhQSnvhDtHC4k79Y2ybtyNJ2tiBAxxAFqFDWdG21Nfqh0NEGbcWzNdjVQ5Kge5lq4= X-Received: by 2002:aca:cdd6:: with SMTP id d205mr4319310oig.90.1576865355675; Fri, 20 Dec 2019 10:09:15 -0800 (PST) MIME-Version: 1.0 References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com> In-Reply-To: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com> From: Phillip Hallam-Baker Date: Fri, 20 Dec 2019 13:09:04 -0500 Message-ID: To: John Mattsson Cc: "cfrg@irtf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000623f9f059a2693c5" Archived-At: Subject: Re: [saag] [Cfrg] Recommendations Regarding Deterministic Signatures 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: Fri, 20 Dec 2019 18:09:17 -0000 --000000000000623f9f059a2693c5 Content-Type: text/plain; charset="UTF-8" The objections to the deterministic signature approach raised in that NIST paper could be avoided by applying the Kocher blinding approach whose patent has recently expired as I point out in another message. However, there is also NIST interest in threshold cryptography and while {Ed/X}{25519/448} support threshold key generation and threshold decryption and threshold key agreement, RFC8032 does not appear to be viable as a good threshold signature scheme. (It is possible to do multi-signatures of course and I have a defective threshold scheme that might make sense in a TPM environment) I will be submitting an Internet Draft describing threshold key generation and threshold decryption by the end of the year (the code runs) and I should have a threshold key agreement draft shortly after. It would be really nice if we had a threshold signature scheme to complete the set (get that 20% matched set armor rating). In particular, I believe that we need a threshold signature scheme that is non-interactive. This is because I need to be able to explain the scheme to a layperson who does not understand the signature scheme. For example: The Alice+Bob aggregate signature is secure because it is constructed a signature contribution from Alice and a signature contribution from Bob, both of which are secure signatures in their own right and both of which have the same exact construction with respect to Alice and Bob's public key as the aggregate signature does to the aggregate key. --000000000000623f9f059a2693c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= objections to the deterministic signature approach raised in that NIST pap= er could be avoided by applying the Kocher blinding approach whose patent h= as recently expired as I point out in another message.

However, there is also NIST interest in thres= hold cryptography and while {Ed/X}{25519/448} support threshold key generat= ion and threshold decryption and threshold key agreement, RFC8032 does not = appear to be viable as a good threshold signature scheme. (It is possible t= o do multi-signatures of course and I have a defective threshold scheme tha= t might make sense in a TPM environment)

I will be submitting an Internet Draft describing threshold= key generation and threshold decryption by the end of the year (the code r= uns) and I should have a threshold key agreement draft shortly after. It wo= uld be really nice if we had a threshold signature scheme to complete the s= et (get that 20% matched set armor rating).

In particular, I believe that we need a threshold sign= ature scheme that is non-interactive. This is because I need to be able to = explain the scheme to a layperson who does not understand the signature sch= eme. For example: The Alice+Bob aggregate signature is secure because it is= constructed a signature=20 contribution=20 from Alice and a signature contribution from Bob, both of which are secure = signatures in their own right and both of which have the same exact constru= ction with respect to Alice and Bob's public key as the aggregate signa= ture does to the aggregate key.



--000000000000623f9f059a2693c5-- From nobody Fri Dec 20 10:21:26 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 89A6712087E for ; Fri, 20 Dec 2019 10:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 rUxcNzj0ykmP for ; Fri, 20 Dec 2019 10:21:24 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AC312087A for ; Fri, 20 Dec 2019 10:21:23 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id p125so2927902oif.10 for ; Fri, 20 Dec 2019 10:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iTXFdF8Dwfw03ev9enjwsrFqb81yy4d9IGoEuwH7kWk=; b=cUNyquHuTsmcVjkmpo5Wd4e5UAGzl9MiJfOKESYHXOTh0RmRyrSFiiVf8SQvJGQf7r 4n7cLPNNtjW9KFArMM7N+TtZpu/LERU661VgTEVfI+zDb1joEDXU+A4RjzfeWSW+PYiM qVMMilGwrXaQGMx8xTpx+2XxPxn9ZAfWwKG8dNKPb/jFrEoFDxV91zlPWUZTt25A/IK+ SUG/9q8ughEC8WIX81tst3wE+bZF75XNe/0BxUgPXUDythWJUxwAXGC/J/ybwA5jTdRX +QswGEk9sVyv6F/s3btxWCOXl/L1h7dVFNL4krXTZxY0uiDAK2bae9+EoB81HtsDVOjO QhFA== 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=iTXFdF8Dwfw03ev9enjwsrFqb81yy4d9IGoEuwH7kWk=; b=kQjHEPt9Dk8x2SQfoQruyiplTHB9vEYH9bak4YUNQe5R4XD5pNqr85EQPiJhB9+XEh fcDTngMHoul4ak4xnnw3ymWuaekzlRZjMq5L30S75qKFJbzz1oQLTa8YUAo+1HQb2Y1z hG8IBV4j0R2JI5e92A1YQ8GD3bD1shl7OohAMiJ3et5ZhaX6ePDYeDoAUm9/zuJozPLq WJP8EsK3g2Y8NwxdR6j/8kz7zCc5RZWbIOxibsTm3kGu2IN9tAF80BexOfbGjpofhi73 9BAwxFy6LHZ1o6AOem05MCXD1u+bH3Q63+rfZpazhYyMczCVN+OLDRGkkGHoYDElJQpy xyeA== X-Gm-Message-State: APjAAAVpVqxjPhRGngdjkw+ye7WVM7Y3BnAIcaiqSJkd1BfH3YVtF0Vq YdrE17W9lCyhWF6mwcHUyHxfRQYenj3siv3CCXs= X-Google-Smtp-Source: APXvYqyrQviT/Af+WbgqN5FOYs6ibXRBzNwymuMQL6pQmeH4KNzrUk8pBTjg/4Z/8QMQAlJrAkX6yiovqoUeH5ZJWoQ= X-Received: by 2002:aca:1302:: with SMTP id e2mr4682390oii.26.1576866083131; Fri, 20 Dec 2019 10:21:23 -0800 (PST) MIME-Version: 1.0 References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com> In-Reply-To: From: Tony Arcieri Date: Fri, 20 Dec 2019 10:21:12 -0800 Message-ID: To: Phillip Hallam-Baker Cc: John Mattsson , "cfrg@irtf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000be55f9059a26bee7" Archived-At: Subject: Re: [saag] [Cfrg] Recommendations Regarding Deterministic Signatures 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: Fri, 20 Dec 2019 18:21:25 -0000 --000000000000be55f9059a26bee7 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 20, 2019 at 10:09 AM Phillip Hallam-Baker wrote: > In particular, I believe that we need a threshold signature scheme that is > non-interactive. This is because I need to be able to explain the scheme to > a layperson who does not understand the signature scheme. For example: The > Alice+Bob aggregate signature is secure because it is constructed a > signature contribution from Alice and a signature contribution from Bob, > both of which are secure signatures in their own right and both of which > have the same exact construction with respect to Alice and Bob's public key > as the aggregate signature does to the aggregate key. > There's already draft-irtf-cfrg-bls-signature work which supports offline/non-interactive aggregation. BLS trivially supports threshold signatures (although I don't see much mention of that in that draft). https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/ Aside from a pairings-based scheme like BLS, I don't believe it's possible to support offline/non-interactive aggregation using (EC)DLP security alone, but I could be mistaken. -- Tony Arcieri --000000000000be55f9059a26bee7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 20, 2019 at 10:09 AM Phillip = Hallam-Baker <phill@hallambaker= .com> wrote:
In particular, I believe that we need a threshold signature scheme th= at is non-interactive. This is because I need to be able to explain the sch= eme to a layperson who does not understand the signature scheme. For exampl= e: The Alice+Bob aggregate signature is secure because it is constructed a = signature=20 contribution=20 from Alice and a signature contribution from Bob, both of which are secure = signatures in their own right and both of which have the same exact constru= ction with respect to Alice and Bob's public key as the aggregate signa= ture does to the aggregate key.

There's already=C2=A0draft-irtf-cfrg-bls-signature work which supports= offline/non-interactive aggregation. BLS trivially supports threshold sign= atures (although I don't see much mention of that in that draft).
=

=C2=A0
Aside from a pairings-based sc= heme like BLS, I don't believe it's possible to support offline/non= -interactive aggregation using (EC)DLP security alone, but I could be mista= ken.

--
Tony Arcieri
--000000000000be55f9059a26bee7-- From nobody Fri Dec 20 11:53:40 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 B4ABB1209D3 for ; Fri, 20 Dec 2019 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 KQe5_y87Dm4p for ; Fri, 20 Dec 2019 11:53:28 -0800 (PST) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (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 6F9691209D0 for ; Fri, 20 Dec 2019 11:53:28 -0800 (PST) Received: by mail-oi1-f176.google.com with SMTP id p67so5230558oib.13 for ; Fri, 20 Dec 2019 11:53:28 -0800 (PST) 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=BTfeKcKgIb00koHYvxxkIZ7xCHBqE5WS1pUhPx9mT4s=; b=IwHAF+1m/A+7me7eldXlVdhvxqfthCi+a5pgadSqRPCS9sfLA2RNQ9Qpv6zM7VdnZh nvxTrRToJSq0WFj0gi4VjywQKnnzHsi4d5P8Mkkg3QA25rKK9ixym+Azm2YLJwgDuPRQ cV13S28MpcIiZh+gI6Y84TPWO6vwkV7whKU+8PaTO+G7dIA1+0f7oTEZY6YO7+qW1Mks Z6Nj/LT9iK8iVWnwl4jbWxS5+Tb9XY3e3P3Mk0lRQgF41GYnfodf7tyVr/mT2/5YKuBP Ns1726/QiMU0uDtpRGxHsrrxwgBWnwkTiidj1zQ6jdXa2TSYwPlAmDL5bwTcfyZ+KqAN 8SRg== X-Gm-Message-State: APjAAAXyYV2+z/BsDL/UKub3FT8x2UEtjfs+hqikrYHRc+X8UwLOWXNb CGRSy8dUhJ92TWTRR3XAfW6xAbXbWhp1Ej3pzzM= X-Google-Smtp-Source: APXvYqwOioqXmOoNpc97y0QW/+VyraI+sL/68WFkwuit/9h2vj76Q+/4WaXjga8mYkPmli50oDs+5e+8tmuLc0YNsOU= X-Received: by 2002:aca:4106:: with SMTP id o6mr4703804oia.173.1576871607761; Fri, 20 Dec 2019 11:53:27 -0800 (PST) MIME-Version: 1.0 References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com> In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 20 Dec 2019 14:53:16 -0500 Message-ID: To: Tony Arcieri Cc: John Mattsson , "cfrg@irtf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000098129059a280815" Archived-At: Subject: Re: [saag] [Cfrg] Recommendations Regarding Deterministic Signatures 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: Fri, 20 Dec 2019 19:53:30 -0000 --000000000000098129059a280815 Content-Type: text/plain; charset="UTF-8" Does this scheme work? It was brought up on the NIST list. https://eprint.iacr.org/2018/068 It would require some changes to RFC8032. But if it is secure (and I have not read it deeply enough to even start on an opinion) and we could modify it to use the Ed448 curve it would be a win. The signatures are not deterministic and they are not RFC8032 compliant but if we could do something that would pass RFC8032 validation, even better. On Fri, Dec 20, 2019 at 1:21 PM Tony Arcieri wrote: > On Fri, Dec 20, 2019 at 10:09 AM Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> In particular, I believe that we need a threshold signature scheme that >> is non-interactive. This is because I need to be able to explain the scheme >> to a layperson who does not understand the signature scheme. For example: >> The Alice+Bob aggregate signature is secure because it is constructed a >> signature contribution from Alice and a signature contribution from Bob, >> both of which are secure signatures in their own right and both of which >> have the same exact construction with respect to Alice and Bob's public key >> as the aggregate signature does to the aggregate key. >> > > There's already draft-irtf-cfrg-bls-signature work which supports > offline/non-interactive aggregation. BLS trivially supports threshold > signatures (although I don't see much mention of that in that draft). > > https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/ > > Aside from a pairings-based scheme like BLS, I don't believe it's possible > to support offline/non-interactive aggregation using (EC)DLP security > alone, but I could be mistaken. > > -- > Tony Arcieri > --000000000000098129059a280815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Doe= s this scheme work? It was brought up on the NIST list.

https://eprint.iacr.org/2018/068=C2=A0
=C2=A0
It would require some changes to RFC8032. But if i= t is secure (and I have not read it deeply enough to even start on an opini= on) and we could modify it to use the Ed448 curve it would be a win. The si= gnatures are not deterministic and they are not RFC8032 compliant but if we= could do something that would pass RFC8032 validation, even better.
<= div class=3D"gmail_default" style=3D"font-size:small">

<= div class=3D"gmail_quote">
On Fri, Dec= 20, 2019 at 1:21 PM Tony Arcieri <= bascule@gmail.com> wrote:
On Fri, Dec 20, 2019 at = 10:09 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
In particular, I believe that we ne= ed a threshold signature scheme that is non-interactive. This is because I = need to be able to explain the scheme to a layperson who does not understan= d the signature scheme. For example: The Alice+Bob aggregate signature is s= ecure because it is constructed a signature=20 contribution=20 from Alice and a signature contribution from Bob, both of which are secure = signatures in their own right and both of which have the same exact constru= ction with respect to Alice and Bob's public key as the aggregate signa= ture does to the aggregate key.

There's already=C2=A0draft-irtf-cfrg-bls-signature work which supports= offline/non-interactive aggregation. BLS trivially supports threshold sign= atures (although I don't see much mention of that in that draft).
=

=C2=A0
Aside from a= pairings-based scheme like BLS, I don't believe it's possible to s= upport offline/non-interactive aggregation using (EC)DLP security alone, bu= t I could be mistaken.

--
Ton= y Arcieri
--000000000000098129059a280815-- From nobody Fri Dec 20 11:57:49 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 E10051209D0 for ; Fri, 20 Dec 2019 11:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QQ7mG5DQKB7i for ; Fri, 20 Dec 2019 11:57:45 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 8652F1209CF for ; Fri, 20 Dec 2019 11:57:45 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id h9so10618481otj.11 for ; Fri, 20 Dec 2019 11:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lUrrgD7QBN2NLgsOM7EyEHai/AxqkZ1FYXqi8w8RWpw=; b=Qzl9Hc0NL8ncxp4iMZIcy4Es3Ae+xcwmV5mFA2bZYA7ULY1fsWxl/OZN8U+eSe89/0 lRllN7Qlj3lcK9TcweRqWZNSaoJMqJZrJ+oNyS5Hq6AxRd1xRZpUUi02p44t1+7szfqB a5Eb8w3eX1GyicMsdCFqOsv16sHUfomIos8SbRgGRn20MEqeziDBRYPS7hz90gRNrs2l RIBQKRbIDZ+eQNazMYVfEwPQi/Uzf1Ho7hdVUlcsRleVGcBf0hLlE2GXzjebRZTOgNyg JVbv/6+crGG4c6nYhCoAK3zl3/dNyVoaLKDJ3ySbEfAfidg/rQxlPdKIfVPzrLEWi2b9 QB2Q== 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=lUrrgD7QBN2NLgsOM7EyEHai/AxqkZ1FYXqi8w8RWpw=; b=IOc09tbpeTEt4AOYS+EAg+9jCiCosccJoYbxBBt5RxY5nUW/YlswiR/7qaiB+l/L4t HadXuibB6goEG6R0M+PYZutJYEQr1w0RxhMGCVrxJIwtSVyY9cJp2sQajKP8RnzaLzCI wuVyGQgcelWM/yWM//6PJTHpetWp49RnQpC4tB50jeP/QohFQSNvksTgtgYkJWaWMUi9 dHEAJ35NSonoI7dxtSE+nyApiQcLuF0dvNGROB0BeO4wRPNT243+72W0aNKGXdNYogoO bRom8uTOVRrVWQOrCWT3AYP4wzkkhG+sT0TkX54u7pu4fA5TnTs3HR0xNuVG57iLmXlw MbZw== X-Gm-Message-State: APjAAAUWRHL5W5FoEcr+llDp96nM/M3htIbtZAOIB8T4hjIzYEzB2w+Z ge1FYnTGFt85WKSG3cjzk5t+Kih8748577iF3ho= X-Google-Smtp-Source: APXvYqwsESLjX3VH6l0jNj8uCt5hiFyPCjScvifmFJ05LAospm7pK2wkNB7yzEH1eOqbQIUkcijXnffW4NwvkLl2w2A= X-Received: by 2002:a05:6830:18f1:: with SMTP id d17mr11387834otf.298.1576871864838; Fri, 20 Dec 2019 11:57:44 -0800 (PST) MIME-Version: 1.0 References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com> In-Reply-To: From: Tony Arcieri Date: Fri, 20 Dec 2019 11:57:34 -0800 Message-ID: To: Phillip Hallam-Baker Cc: John Mattsson , "cfrg@irtf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005c2fb1059a2817d2" Archived-At: Subject: Re: [saag] [Cfrg] Recommendations Regarding Deterministic Signatures 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: Fri, 20 Dec 2019 19:57:48 -0000 --0000000000005c2fb1059a2817d2 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 20, 2019 at 11:53 AM Phillip Hallam-Baker wrote: > Does this scheme work? It was brought up on the NIST list. > > https://eprint.iacr.org/2018/068 > MuSig is a 3-round interactive protocol -- Tony Arcieri --0000000000005c2fb1059a2817d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 20, 2019 at 11:53 AM Phillip = Hallam-Baker <phill@hallambaker= .com> wrote:
Does this scheme work? It was brought up on the NIST list.


MuSig is a 3-= round interactive protocol=C2=A0

--
Tony Arcieri
--0000000000005c2fb1059a2817d2-- From nobody Fri Dec 20 11:59:47 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 DC5041209BD for ; Fri, 20 Dec 2019 11:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 DQ6hRDUoKcAi for ; Fri, 20 Dec 2019 11:59:39 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 4D6AC1209D0 for ; Fri, 20 Dec 2019 11:59:39 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id a15so13233327otf.1 for ; Fri, 20 Dec 2019 11:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nIKx6YFC78pM5vNBgxAlMrgZkvd9c89DD10cMOdRuxo=; b=aDhnOKr0EZV8HL/oyH/9k4wB+zWLxaQbK8KaHDH3CCR4/NMH+x9PzLY6Iut90v9wD2 Bp1nlx+wMtymhTm7EQDxlWh+bXGoEfUrKjcDGAzLTnnwHkl04o7p1iOpPE9nhNGLPZ+V Bdw/qIpyyKpEu8TXZJ/qc9w/bcLOmY9w7ngyxyIkSa+ypmKKpnZ2njd3Ictke2vaoEzo ijhSaBbjEL3uL4h/mUOc6cJlMFB3CBN2lFCkAwPpXg4Fo61Dmgnpsb/EaEyuN08vKjk3 IiP4ax6DdgTs7NxtFNTtiXmkbjZFNX64O7bWThGoSRdAx2k7Z8sGU6RYz/SZIGYKKXt6 T9pg== 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=nIKx6YFC78pM5vNBgxAlMrgZkvd9c89DD10cMOdRuxo=; b=LUfcQgZN9Z3TjN/fn5RCVoo4LH+2/7ce4zL/7fJoCjKhuv8k9jnewGm8qCdGWAeTa0 kFEvljQxOh4BGefcN+v1lDukrYy/EdfhkStCQ9SsnPV7EYO1i8tmh3p/ieBNSAy+v2dQ xvKchy1+tV3/2L9AM7FN1hiQIsXpwp7OyfC0QcvoJ7MdjZ0tDD5a6t3G689sJ7nQv4wD ULxnYT0EXG+Ve3qVptdEXI02VXL/Y01AYG2CM0O2+7wmg6kxAkvwCC7O10Ga6JmB05Z1 XtApK+mGEx3Pce29/B9AeDxDbuq2tw8MYgRu4+NYpVlmSwTR5B3wzIwKLRxG0t1E5XLC CdIQ== X-Gm-Message-State: APjAAAU1lXSxmiBojsTfBzxGUj97uAKA+AwDOIlSrAXpi1Zf5nlJuBN7 QouTpF5M+yAq6N4C2cdF1mOEnjeE1DQGIz3Pl/0= X-Google-Smtp-Source: APXvYqz5CtBzR5tJdDmra+MOlkPqrwmECkvrbzJGQ6bI4iNfsrKoFnqv1Kx/7IrToZArNc0MEE9eskqTRn/v0oZ3zUA= X-Received: by 2002:a05:6830:18e9:: with SMTP id d9mr8295939otf.332.1576871978553; Fri, 20 Dec 2019 11:59:38 -0800 (PST) MIME-Version: 1.0 References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com> In-Reply-To: From: Tony Arcieri Date: Fri, 20 Dec 2019 11:59:27 -0800 Message-ID: To: Phillip Hallam-Baker Cc: John Mattsson , "cfrg@irtf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000235556059a281e21" Archived-At: Subject: Re: [saag] [Cfrg] Recommendations Regarding Deterministic Signatures 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: Fri, 20 Dec 2019 19:59:42 -0000 --000000000000235556059a281e21 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 20, 2019 at 11:57 AM Tony Arcieri wrote: > MuSig is a 3-round interactive protocol > Also note that if you're okay with a 3-round interactive protocol, you can do the same sort of thing with Ed25519: https://github.com/KZen-networks/multi-party-eddsa -- Tony Arcieri --000000000000235556059a281e21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 20, 2019 at 11:57 AM Tony Arc= ieri <bascule@gmail.com> wro= te:
MuSig is a 3-round interac= tive protocol

Also note t= hat if you're okay with a 3-round interactive protocol, you can do the = same sort of thing with Ed25519:


--
Tony Arcieri
--000000000000235556059a281e21-- From nobody Sat Dec 28 10:02:05 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 6E2DA12013C; Sat, 28 Dec 2019 10:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 c9B-05-uFK6C; Sat, 28 Dec 2019 10:02:02 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id AB98F120154; Sat, 28 Dec 2019 10:02:02 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.57.14]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xBSI1gJD014217 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Dec 2019 10:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1577556115; x=1577642515; i=@elandsys.com; bh=hfFrYxAiTora/SA+HTCiXwQ2aKmUu2401ExK2WT8OAE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=szk+eBSxzB8wiDFtZ1a//P8gLUWQpHL+qjEjfC9EigjbhAvDeEh+0ll17XwboQ0Hd 9hqJJo1rGmH4Jg0ru5tf0YkaMK88IwzGDczQ1rOsZO6DlIo7PfrKqIJi9uLrUGCX+N Qgz+CHE6qIiKfGrBES62gICTDr/sdEXyfIdBTYO0= Message-Id: <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 28 Dec 2019 09:58:46 -0800 To: saag@ietf.org, draft-foudil-securitytxt@ietf.org From: S Moonesamy In-Reply-To: <157591314890.2123.12378772921757205119.idtracker@ietfa.ams l.com> References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [saag] Last Call: (A Method for Web Security Policies) to Informational RFC 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, 28 Dec 2019 18:02:03 -0000 At 09:39 AM 09-12-2019, The IESG wrote: >The IESG has received a request from an individual submitter to consider the >following document: - 'A Method for Web Security Policies' > as Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits final >comments on this action. Please send substantive comments to the >last-call@ietf.org mailing lists by 2020-01-06. Exceptionally, comments may Section 1.1 of the draft states that it is about helping organizations to communicate information about their security disclosure policies. Is the field defined in Section 3.5.6 optional? Section 3 sets a requirement for the file (security.txt) to be accessible via HTTP and references RFC 1945. Does it mean that the file must be accessible using HTTP/1/0? Section 3.1 specifies that the file would only apply to the domain in the URI. The examples given in that section states that the file also applies to to IPv4 and IPv6 addresses. There is a requirement in Section 3.3 for the line separator to be either CRLF or LF. Have the authors considered using only one convention for specifying the end of line? Have the authors considered line limits given that the specification defines a machine-parsable format? Why does the robustness principle require capital letters? (Section 4)? How will the designated expert determine whether a proposed registration (Section 7.2) provides value? What is the "wider Internet community"? How should "MAY assume that English is the default language to be used" be interpreted (Section 3.5.7)? RFC 2777 states that "i-default" is not a specific language. As an overall comment, there are a lot of requirements and recommendations (please see RFC 2119) in the draft. There is, for example, a restatement of a requirement: "The value MUST follow the URI syntax described in [RFC3986]. This means that "mailto" and "tel" URI schemes MUST be used when specifying email addresses and telephone numbers, as defined in [RFC6068] and [RFC3966]". Does that comply with the ABNF defined in Section 5? Regards, S. Moonesamy From nobody Sat Dec 28 19:59:19 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 B77B312023E for ; Sat, 28 Dec 2019 19:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 TA-uYKzhEwHh for ; Sat, 28 Dec 2019 19:59:10 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 0E76C120232 for ; Sat, 28 Dec 2019 19:59:10 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id b137so16458414pga.6 for ; Sat, 28 Dec 2019 19:59:10 -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=Oe4HFKcceQOBF9N2Obb3eKMfAJjW1m1hEZb0x29gUgY=; b=M1Dzo1o9ucwQ4q+o3h5dXpXhrR17IGadujqQG8mHCSNc8zoFms0d/VVSSGUlClg9e8 aF+PNaWZ9n99lC8kdhoFm7MLQr8kgo6h7J2Ve1okzg/oxjC9OscAGehbOxU/m8VInnBW l4BmQB+UXTudvuzk6DrWbmB17UW0YpkEAF5y6I49tGUDpSO//1Wl/6KnqP5cc0PgWFIB CCYNRgc1OFJyHZ9dDq0NYJ+Dgdz7PvYAMnxcTK6GokBmz6FSXxJbXPbGsBjrcauWPfq5 SKlfB+00H0lughdgt1vQDrAwmMzxu5LoM0CGq3SgMXpE5mrFQASLaoyE41qcRVCRZ+Qu dNxg== 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=Oe4HFKcceQOBF9N2Obb3eKMfAJjW1m1hEZb0x29gUgY=; b=QeHXkk11evr2TFvCQ0+elGe4hHDzWY8KkbwnsxsP5jZeY4+uNPejtTjXjrOFnlkLmw i2zypP+sBmz+uSmLAfelTrpiSxoOkTuPMDS3UoMF2AvOI/PDE74DrSZBhveGP8XlvhoP g9ncT3ua3NRsIxlCOTtFlEOCvz7wfOR7t9zrUx6ULgNtREAgZsuE1GQblKliKjq4WpWp 9g4JtCunkzIDVx6EeL2q2M9UQHRdtcankzTfZjAZwP32iawE9Xe8TtAw1wJuDveCYH5c 2RQiDjsmM1sHI8HTusR4zvry+x6SFiFj/1O7GrISUex14CH6XBfeH8qiWgd1iIYh1gWE iEqw== X-Gm-Message-State: APjAAAUx0runFh0tb3azEGLxybShiELUJT7BE7IgSM35CbpEMp6x9+mo rYZl9QG5p6+cBzb9ETcAavT5X3oKED9aFKGEm8iI6w== X-Google-Smtp-Source: APXvYqx5V76zQsnlkMWbrfiSUWu578wMmaKbv1qGmLQXwcWJs5r0JKjpVljNFwbIAyLvQ6AMMbhbFylZwG7lRg+J1yo= X-Received: by 2002:a63:954f:: with SMTP id t15mr62917134pgn.137.1577591949278; Sat, 28 Dec 2019 19:59:09 -0800 (PST) MIME-Version: 1.0 References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> In-Reply-To: <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> From: Yakov Shafranovich Date: Sat, 28 Dec 2019 22:58:33 -0500 Message-ID: To: S Moonesamy Cc: Security Area Advisory Group , draft-foudil-securitytxt@ietf.org, Kathleen Moriarty , last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Last Call: (A Method for Web Security Policies) to Informational RFC 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, 29 Dec 2019 03:59:12 -0000 On Sat, Dec 28, 2019 at 1:02 PM S Moonesamy wrote: > > Section 1.1 of the draft states that it is about helping > organizations to communicate information about their security > disclosure policies. Is the field defined in Section 3.5.6 optional? > All fields are optional except for the "Contact" directive so at a minimum, there is a way to contact the organization even without a published policy. > Section 3 sets a requirement for the file (security.txt) to be > accessible via HTTP and references RFC 1945. Does it mean that the > file must be accessible using HTTP/1/0? > Are you saying we should only allow HTTP 1.1 or 2.0? If so, I would argue that HTTP 1.0 must be allowed. > Section 3.1 specifies that the file would only apply to the domain in > the URI. The examples given in that section states that the file > also applies to to IPv4 and IPv6 addresses. > Being that it is referencing the URI format, the intent is the host as per section 3.2.2 of RFC 3986. That would include both domain names and IP addresses. We would need to clarify the language to match. > There is a requirement in Section 3.3 for the line separator to be > either CRLF or LF. Have the authors considered using only one > convention for specifying the end of line? > > Have the authors considered line limits given that the specification > defines a machine-parsable format? > There is an ongoing issue with some systems supporting CRLF and some only LF, which is why we defined in a more fluid way. This is somewhat similar to section 3.5 in RFC 7230 (HTTP 1.1): Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. > Why does the robustness principle require capital letters? (Section 4)? > I am not sure about this question - can you clarify? > How will the designated expert determine whether a proposed > registration (Section 7.2) provides value? What is the "wider > Internet community"? > Well, from the various feedback received so far, there are certainly strong opinions expressed whether the proposal itself and many of its parts provide value at all :) All jokes aside, we didn't want the registry to be a free for all via "First Come First Served" on the one extreme, and be completely restricted ("IESG Approval") on the other extreme. We felt an expert review would provide the right amount of oversight so something crazy doesn't get shoved into the registry. A good example of this would be a proposal of a directive indicating that the researcher doesn't have permission to test any of the assets - something we couldn't reach consensus on earlier. This would be something that would benefit from a review by someone versed in security and standards. The wider community would be the researchers and organizations using this format. > How should "MAY assume that English is the default language to be > used" be interpreted (Section 3.5.7)? RFC 2777 states that > "i-default" is not a specific language. > The reference is to the following language in RFC 2277: When human-readable text must be presented in a context where the sender has no knowledge of the recipient's language preferences (such as login failures or E-mailed warnings, or prior to language negotiation), text SHOULD be presented in Default Language. And: Messages in Default Language MUST be understandable by an English- speaking person, since English is the language which, worldwide, the greatest number of people will be able to get adequate help in interpreting when working with computers. Note that negotiating English is NOT the same as Default Language; Default Language is an emergency measure in otherwise unmanageable situations. Basically, we wanted to come up with a safe default and that was the best reference that seemed to indicate that English may be used in this case. > As an overall comment, there are a lot of requirements and > recommendations (please see RFC 2119) in the draft. There is, for > example, a restatement of a requirement: "The value MUST follow the > URI syntax described in [RFC3986]. This means that "mailto" and > "tel" URI schemes MUST be used when specifying email addresses and > telephone numbers, as defined in [RFC6068] and [RFC3966]". Does that > comply with the ABNF defined in Section 5? > The earlier versions of the draft allowed contact information without the full URI which is why the current draft calls this out. In the ABNF grammar (section 5), URI references RFC 3986. The assumption is that this reference also includes the IANA and all relevant RFCs that define URIs, since it would be impractical to list all of them out in our draft. Perhaps, the use of RFC 2119 keywords in this specific section may not be needed, since the MUST for URI syntax would be sufficient. Thanks From nobody Sun Dec 29 00:07:21 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 94F80120090; Sun, 29 Dec 2019 00:07:19 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 3GK3bXYNe0Kt; Sun, 29 Dec 2019 00:07:16 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FFD12004E; Sun, 29 Dec 2019 00:07:16 -0800 (PST) Received: from client-0034.vpn.uni-bremen.de (client-0034.vpn.uni-bremen.de [134.102.107.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47ltSy0hLNz16pj; Sun, 29 Dec 2019 09:07:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> Date: Sun, 29 Dec 2019 09:07:13 +0100 Cc: saag@ietf.org, draft-foudil-securitytxt@ietf.org X-Mao-Original-Outgoing-Id: 599299631.5562249-685185c6490a10db3d393e1b0e1f9de3 Content-Transfer-Encoding: quoted-printable Message-Id: References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [saag] Last Call: (A Method for Web Security Policies) to Informational RFC 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, 29 Dec 2019 08:07:20 -0000 On Dec 28, 2019, at 18:58, S Moonesamy wrote: >=20 > Have the authors considered line limits given that the specification = defines a machine-parsable format? Don=E2=80=99t do that (putting in artificial limitations into a new spec = can sometimes be faintly legitimized by legacy considerations, such as = in MIME 8bit, but usually only has negative consequences). > Why does the robustness principle require capital letters? (Section = 4)? I don=E2=80=99t see a reference to RFC 1123 there. I think the BCP14 = language in that section is justified, with the possible exception of Any directives registered via that process MUST be considered optional. (What? Considered by whom? What does =E2=80=9Cconsidered optional=E2=80=9D= actually mean? Does =E2=80=9Cthat process=E2=80=9D include the = directives registered by the proposed document?) .oOo. Obviously, I=E2=80=99m not a fan of standardizing yet another ad-hoc = parser, but this may be legitimized here by legacy considerations. (I = believe the CRLF handling is appropriate.) I also see the problems with = staleness and verification. I think requiring a mandatory expiration date in every security.txt = could help a bit with the staleness issue. I also believe this text need some good reread. E.g., the following two = sentences lead to obvious nonsense: =C2=BB This text file contains = multiple directives with different values. The "directive" is the first part of a field all the way up to the colon ("Contact:") and follows the syntax defined for "field-name" in section 3.6.8 of [RFC5322]. =C2=AB Do the values really need to be different? Isn=E2=80=99t the file = containing fields, not just the directives (which demonstrates that = =E2=80=9Cdirective=E2=80=9D is a bad name for a directive name)? Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Dec 29 01:39:30 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 0DF1512004E; Sun, 29 Dec 2019 01:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 uiOcSexxNdlT; Sun, 29 Dec 2019 01:39:26 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A84AF12002F; Sun, 29 Dec 2019 01:39:26 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.57.14]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xBT9dAqR003271 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Dec 2019 01:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1577612363; x=1577698763; i=@elandsys.com; bh=Y5mwMG4AWymiGFGOO5YWL1DZrajNUW/Rmj9USQR4gC0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CCe6kNtqtvp+/Yyfejd+jWPkMRnpHxna2QLM7Pidl67949Dy4gLbi13QCEzkYt4MH fTTh9Ynmyj5cLMN1n6ONsCHeWWxbIRs2USD22V8i857Vfr9Bf/0vRQFmgwyyDwXlJQ jQp9rD36gTRnBopxZF38jJIH8OFkGrkLSIl5WriE= Message-Id: <6.2.5.6.2.20191228215319.0c4ce6b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 29 Dec 2019 01:38:42 -0800 To: Yakov Shafranovich , saag@ietf.org From: S Moonesamy Cc: draft-foudil-securitytxt@ietf.org, Kathleen Moriarty In-Reply-To: References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [saag] Last Call: (A Method for Web Security Policies) to Informational RFC 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, 29 Dec 2019 09:39:28 -0000 Hi Yakov, Thank you for the quick feedback. At 07:58 PM 28-12-2019, Yakov Shafranovich wrote: >All fields are optional except for the "Contact" directive so at a >minimum, there is a way to contact the organization even without a >published policy. The issue identified in the draft is the lack of mechanisms (or methods) for "security researchers" to "locate disclosure policies and contact information for organizations in order to report security vulnerabilities. It doesn't make sense to make the publication of disclosure policies optional as it creates uncertainty. Furthermore, the "SHOULD consult the organization's policy" recommendation in Section 6.7 does not carry much weight when such information is, by default, inaccessible. >Are you saying we should only allow HTTP 1.1 or 2.0? If so, I would >argue that HTTP 1.0 must be allowed. I was actually asking about the meaning of the requirement as the ambiguity leaves the door open to questions such as the above-mentioned one. >Being that it is referencing the URI format, the intent is the host as >per section 3.2.2 of RFC 3986. That would include both domain names >and IP addresses. We would need to clarify the language to match. Ok. >There is an ongoing issue with some systems supporting CRLF and some >only LF, which is why we defined in a more fluid way. This is somewhat >similar to section 3.5 in RFC 7230 (HTTP 1.1): Ok. > > Why does the robustness principle require capital letters? (Section 4)? > > > >I am not sure about this question - can you clarify? There is a reference to RFC 793. Section 2.10 of that document contains a statement about the robustness principle. >Well, from the various feedback received so far, there are certainly >strong opinions expressed whether the proposal itself and many of its >parts provide value at all :) It can happen. :) >All jokes aside, we didn't want the registry to be a free for all via >"First Come First Served" on the one extreme, and be completely >restricted ("IESG Approval") on the other extreme. We felt an expert >review would provide the right amount of oversight so something crazy >doesn't get shoved into the registry. A good example of this would be >a proposal of a directive indicating that the researcher doesn't have >permission to test any of the assets - something we couldn't reach >consensus on earlier. This would be something that would benefit from >a review by someone versed in security and standards. > >The wider community would be the researchers and organizations using >this format. The above explanation is different from the guidance provided in the draft for the review of a new field. You have an idea of what you do not wish to see. I suggest finding the appropriate wording for the criteria. >The reference is to the following language in RFC 2277: > > When human-readable text must be presented in a context where the > sender has no knowledge of the recipient's language preferences (such > as login failures or E-mailed warnings, or prior to language > negotiation), text SHOULD be presented in Default Language. > >And: > > Messages in Default Language MUST be understandable by an English- > speaking person, since English is the language which, worldwide, the > greatest number of people will be able to get adequate help in > interpreting when working with computers. > > Note that negotiating English is NOT the same as Default Language; > Default Language is an emergency measure in otherwise unmanageable > situations. > >Basically, we wanted to come up with a safe default and that was the >best reference that seemed to indicate that English may be used in >this case. I am not sure whether the assumption in the last two paragraphs is still valid. Sometimes, there are strong views about that topic. >The earlier versions of the draft allowed contact information without >the full URI which is why the current draft calls this out. In the >ABNF grammar (section 5), URI references RFC 3986. The assumption is >that this reference also includes the IANA and all relevant RFCs that >define URIs, since it would be impractical to list all of them out in >our draft. Perhaps, the use of RFC 2119 keywords in this specific >section may not be needed, since the MUST for URI syntax would be >sufficient. Ok. Regards, S. Moonesamy From nobody Mon Dec 30 18:05:26 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 698FC12002E for ; Mon, 30 Dec 2019 18:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 oaaVWObCfjxo for ; Mon, 30 Dec 2019 18:05:23 -0800 (PST) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 CBF561200DB for ; Mon, 30 Dec 2019 18:05:23 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id x6so18006974pfo.10 for ; Mon, 30 Dec 2019 18:05:23 -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=AUx7qm7vl+oOrDcfCKvqSgj7+y+XwHqu20U9LmoF1VI=; b=pXb5AD+/1t9m0x6EGEqJubvaGMQMqj8Bi73L3KFpnd1t0PSiXDWy5OppHf7HEewulY goFm19gxxaJxxgST31I87x+CHsdaJt9buYgOCnT6ajvcE9Z/0vJyXWvW3Gz/1MtfySSI PpCKVWkF9rYH7W6NgZHqw0Bkjjh+6bYhPXYQRDy7qdVFp8swKdUXeAWab74Qb5iFKxNM 8Q42FiscSWxPR+AETiV5mODXvgVcEgT79GbCAlffq1eEq0wbjzes4+JTZGUQrS17pUzN QHXrIpdjYl1q01zEiBFlHMwVJGGj5MwE4+dmfpL9ZcNYCnY2htkt2w6OwoQ439kUd5dn 8Diw== 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=AUx7qm7vl+oOrDcfCKvqSgj7+y+XwHqu20U9LmoF1VI=; b=PgzyEl9VZKLxdQtF6NTmwG4ff0pM7VWZ1KoMMlJQtnWt86nByBOVqjE/wu2H4rzDhy Atf8cUIx/zXT8eBBT7ik1YeG6zgqRSh9llKcmXE71oq+1ARcGpanKZ2I3UKDBMLyUUGU lcu0s+puzHEG/zQ2GwfOYRxVfsagUCtytJXIyml6UMLp59fNWCR6GiONHelzqgdCJ+Za jpfVdso6JKZjcZvB3Vf81d4O+Z/nRryG2xeh4q4fkp92bfoXgQ2F1WN3+2Ds2+YWqLWV VuO9BJg3/mjJ6zTLEWKXRAt0TOGUEqVJVkmGWMuwqZJ5GgM/9IsjtxkmOe983HOdQk0u zliw== X-Gm-Message-State: APjAAAVXw3YNcnPJlt8L4Amf3JaUMBE8fsDAGiYOWvBdSz2opj6gOYqX E4eLFeTcm/OWOc4weh3p3r4QO+Rd26kIuR81M2ZffA== X-Google-Smtp-Source: APXvYqyvwoH4SbxR+0m7BRPqD4wjwiBFUtsiEFDCfkK/IsF8NqTV9qZKWDpuqYYFrYJWOd8e5QAYk8g2AEGxjcgKrqk= X-Received: by 2002:a05:6a00:5b:: with SMTP id i27mr76017061pfk.112.1577757923246; Mon, 30 Dec 2019 18:05:23 -0800 (PST) MIME-Version: 1.0 References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> <6.2.5.6.2.20191228215319.0c4ce6b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20191228215319.0c4ce6b8@elandnews.com> From: Yakov Shafranovich Date: Mon, 30 Dec 2019 21:04:47 -0500 Message-ID: To: S Moonesamy Cc: Security Area Advisory Group , draft-foudil-securitytxt@ietf.org, Kathleen Moriarty , last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Last Call: (A Method for Web Security Policies) to Informational RFC 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, 31 Dec 2019 02:05:25 -0000 On Sun, Dec 29, 2019 at 4:39 AM S Moonesamy wrote: > > Hi Yakov, > > Thank you for the quick feedback. > Thank you! I am making changes in Github for now with an expectation of a new draft being published once all feedback has been incorporated. > At 07:58 PM 28-12-2019, Yakov Shafranovich wrote: > >All fields are optional except for the "Contact" directive so at a > >minimum, there is a way to contact the organization even without a > >published policy. > > The issue identified in the draft is the lack of mechanisms (or > methods) for "security researchers" to "locate disclosure policies > and contact information for organizations in order to report security > vulnerabilities. It doesn't make sense to make the publication of > disclosure policies optional as it creates uncertainty. Furthermore, > the "SHOULD consult the organization's policy" recommendation in > Section 6.7 does not carry much weight when such information is, by > default, inaccessible. > Phillip Hallam-Baker pointed a similar issue out related to the title of the draft and the use of the term "policy": https://mailarchive.ietf.org/arch/msg/last-call/DOH5NHcDKeQEVGpWox43w1BHOrE Currently I am thinking of changing the title to: "A Format for Describing Vulnerability Disclosure Practices". With this, contact information would be the bare minimum with an organization's policy a highly recommended thing to include (SHOULD). Because some organizations do not want to disclose their policy publicly, the contact information would be the starting point for a researcher. > >Are you saying we should only allow HTTP 1.1 or 2.0? If so, I would > >argue that HTTP 1.0 must be allowed. > > I was actually asking about the meaning of the requirement as the > ambiguity leaves the door open to questions such as the above-mentioned one. > I would change it to read: "for web-based services, the file MUST be accessible via the Hypertext Transfer Protocol (HTTP) 1.0 [RFC1945] or higher version," > >Being that it is referencing the URI format, the intent is the host as > >per section 3.2.2 of RFC 3986. That would include both domain names > >and IP addresses. We would need to clarify the language to match. > > Ok. I would change it to read: ""MUST only apply to the domain or IP address in the URI used to retrieve it" > > > > Why does the robustness principle require capital letters? (Section 4)? > > > > > > >I am not sure about this question - can you clarify? > > There is a reference to RFC 793. Section 2.10 of that document > contains a statement about the robustness principle. > Fixed to use lower case > > >All jokes aside, we didn't want the registry to be a free for all via > >"First Come First Served" on the one extreme, and be completely > >restricted ("IESG Approval") on the other extreme. We felt an expert > >review would provide the right amount of oversight so something crazy > >doesn't get shoved into the registry. A good example of this would be > >a proposal of a directive indicating that the researcher doesn't have > >permission to test any of the assets - something we couldn't reach > >consensus on earlier. This would be something that would benefit from > >a review by someone versed in security and standards. > > > >The wider community would be the researchers and organizations using > >this format. > > The above explanation is different from the guidance provided in the > draft for the review of a new field. You have an idea of what you do > not wish to see. I suggest finding the appropriate wording for the criteria. > I am rewording this as: "Designated Experts are expected to check whether a proposed registration or update makes sense in the context of industry accepted vulnerability disclosure processes such as {{ISO.29147.2018}} and {{CERT.CVD}}, and provides value to organizations and researchers using this format." > >The reference is to the following language in RFC 2277: > > > > When human-readable text must be presented in a context where the > > sender has no knowledge of the recipient's language preferences (such > > as login failures or E-mailed warnings, or prior to language > > negotiation), text SHOULD be presented in Default Language. > > > >And: > > > > Messages in Default Language MUST be understandable by an English- > > speaking person, since English is the language which, worldwide, the > > greatest number of people will be able to get adequate help in > > interpreting when working with computers. > > > > Note that negotiating English is NOT the same as Default Language; > > Default Language is an emergency measure in otherwise unmanageable > > situations. > > > >Basically, we wanted to come up with a safe default and that was the > >best reference that seemed to indicate that English may be used in > >this case. > > I am not sure whether the assumption in the last two paragraphs is > still valid. Sometimes, there are strong views about that topic. > Some sort of a sane default would be needed here even if it's not perfect. The interpretation described above seems to be similar to what other drafts are doing. For example, see section 2.7 here: https://tools.ietf.org/html/draft-ietf-secevent-http-push-07 If the SET Transmitter did not send an "Accept-Language" header, or if the SET Recipient does not support any of the languages included in the header, the SET Recipient MUST respond with messages that are understandable by an English-speaking person, as described in Section 4.5 of [RFC2277]. Thanks! From nobody Mon Dec 30 19:13: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 8F1181200C1 for ; Mon, 30 Dec 2019 19:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 GxByRBIjN9xT for ; Mon, 30 Dec 2019 19:13:18 -0800 (PST) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 39A1812008F for ; Mon, 30 Dec 2019 19:13:18 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id q8so19162537pfh.7 for ; Mon, 30 Dec 2019 19:13: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=rRmBg7hNH6iF5XKgQhrMXnCcaCp/LpNY2yHoPnUV6wA=; b=1++jwcgqUrso7gGZqXcQCMs/89Kk7/jvWLxyxVdSRsC/wopCEvbgevnEGV80Hnc8Xx QEURmdLEk+Qim2Pyng0fR1HWBfOHhm2Cu1ZxETnSXIjCG/Yq8PFlPnmHkoU2Z8YK8ukx lBc6VhbKH+hsrCA4+ypthgbWlAkzHwnahertPBzSwOxdz/0Sh9VZqPv1hd+mG1HLoLUH Yvt4paKoaPKywiGwjoLXHRoLoZce14hq+l+hABy914TYmqijEe9Vq87LArm9kLKoWVCY 0IUL4zDaAgch65l3B0kEwhwMCzmBOGJrJ+rj9QXQm8SB2b1/Fhui+qzV6Dd+nhQtxEke ZzWw== 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=rRmBg7hNH6iF5XKgQhrMXnCcaCp/LpNY2yHoPnUV6wA=; b=lZzgmp1T4lfvurXN+tdtBcERDv6rW7eXE3YL3sosAzWYbGRetZk8+z16IrfgKzezOW u+OlJsHsNnpLg2EyrOcNIPIqxonJpdZ5dvUmgkauQyvnAwfRbjbfTp728hsJ3AHSZc6N GW4iRXsZ5urqCgW4ob3GSuKj+RJXv8ZFNagjIYA0ZGY3uQipoDSgYLdh6Sko+5VH4wdY m5bRn9Z1FeHznQvizU7YDxsyq00gmjlZb6m/JtjWhtsA6Eb6U03ccQDyEVbm0ZRn0hu3 LTRIXFPmeVn93G7VQKg1eb/ezMvtogVItN3E0fQfWFCyDYJJ2Mm5JNapaJMcjYCB5Gev 34cA== X-Gm-Message-State: APjAAAUxJsjINrMUghJY5qApm8Ewut7UWhcfJwJpYPiq607faJy4bPL1 V1MsJB9mUIu8biO554ohHSDyZaFHQnKVl2mEMLCZPSDdWmI= X-Google-Smtp-Source: APXvYqxQw9iMnGSaVj+vCmSX07f5nha07IIplbuNxYYyPGtMInEyYu74kN7mQKyqqLC5nac/6zNRz5J2Ovlyn+YOx9U= X-Received: by 2002:a63:954f:: with SMTP id t15mr74581985pgn.137.1577761997371; Mon, 30 Dec 2019 19:13:17 -0800 (PST) MIME-Version: 1.0 References: <157591314890.2123.12378772921757205119.idtracker@ietfa.amsl.com> <6.2.5.6.2.20191228083545.0bcd8a78@elandnews.com> In-Reply-To: From: Yakov Shafranovich Date: Mon, 30 Dec 2019 22:12:41 -0500 Message-ID: To: Security Area Advisory Group Cc: last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Last Call: (A Method for Web Security Policies) to Informational RFC 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, 31 Dec 2019 03:13:19 -0000 On Sun, Dec 29, 2019 at 3:07 AM Carsten Bormann wrote: > On Dec 28, 2019, at 18:58, S Moonesamy wrote: > > Any directives registered > via that process MUST be considered optional. > > (What? Considered by whom? What does =E2=80=9Cconsidered optional=E2=80= =9D actually mean? Does =E2=80=9Cthat process=E2=80=9D include the directi= ves registered by the proposed document?) > The concern was that once the draft is published, defining additional required fields via the registry may lead to compatibility issues between the people doing the publishing and the researchers parsing the files. However, since the next sentence says that people reading/parsing the file should ignore anything not supported, perhaps this is not needed? "To encourage extensibility and interoperability, implementers MUST ignore any fields they do not explicitly support." > .oOo. > > Obviously, I=E2=80=99m not a fan of standardizing yet another ad-hoc pars= er, but this may be legitimized here by legacy considerations. (I believe = the CRLF handling is appropriate.) I also see the problems with staleness a= nd verification. > I think requiring a mandatory expiration date in every security.txt could= help a bit with the staleness issue. > That is a great idea, I am going to add an "Expires" field to the draft and some language in the security section around that as well. > I also believe this text need some good reread. E.g., the following two = sentences lead to obvious nonsense: =C2=BB This text file contains multip= le directives with different values. > The "directive" is the first part of a field all the way up to the > colon ("Contact:") and follows the syntax defined for "field-name" in > section 3.6.8 of [RFC5322]. =C2=AB > Do the values really need to be different? Isn=E2=80=99t the file contai= ning fields, not just the directives (which demonstrates that =E2=80=9Cdire= ctive=E2=80=9D is a bad name for a directive name)? > Will address this by calling them fields, names and values instead of direc= tives On Mon, Dec 30, 2019 at 10:10 PM Nightwatch Cybersecurity Research wrote: > > On Sun, Dec 29, 2019 at 3:07 AM Carsten Bormann wrote: > > On Dec 28, 2019, at 18:58, S Moonesamy wrote: > > > > Any directives registered > > via that process MUST be considered optional. > > > > (What? Considered by whom? What does =E2=80=9Cconsidered optional=E2= =80=9D actually mean? Does =E2=80=9Cthat process=E2=80=9D include the dire= ctives registered by the proposed document?) > > > > The concern was that once the draft is published, defining additional > required fields via the registry may lead to compatibility issues > between the people doing the publishing and the researchers parsing > the files. However, since the next sentence says that people > reading/parsing the file should ignore anything not supported, perhaps > this is not needed? > > "To encourage extensibility and interoperability, implementers MUST > ignore any fields they do not explicitly support." > > > .oOo. > > > > Obviously, I=E2=80=99m not a fan of standardizing yet another ad-hoc pa= rser, but this may be legitimized here by legacy considerations. (I believ= e the CRLF handling is appropriate.) I also see the problems with staleness= and verification. > > I think requiring a mandatory expiration date in every security.txt cou= ld help a bit with the staleness issue. > > > > That is a great idea, I am going to add an "Expires" field to the > draft and some language in the security section around that as well. > > > I also believe this text need some good reread. E.g., the following tw= o sentences lead to obvious nonsense: =C2=BB This text file contains mult= iple directives with different values. > > The "directive" is the first part of a field all the way up to the > > colon ("Contact:") and follows the syntax defined for "field-name" i= n > > section 3.6.8 of [RFC5322]. =C2=AB > > Do the values really need to be different? Isn=E2=80=99t the file cont= aining fields, not just the directives (which demonstrates that =E2=80=9Cdi= rective=E2=80=9D is a bad name for a directive name)? > > > > Will address this by calling them fields, names and values instead of dir= ectives