IETF Logo Mail Archive

[Add] Threat models

Paul Hoffman <paul.hoffman@icann.org> Tue, 30 June 2020 17:47 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAACA3A0802 for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 10:47:10 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8QXq2r-JPoU for <add@ietfa.amsl.com>; Tue, 30 Jun 2020 10:47:09 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 277B43A07ED for <add@ietf.org>; Tue, 30 Jun 2020 10:47:09 -0700 (PDT)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05UHl81r001051 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 17:47:08 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 30 Jun 2020 10:47:06 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Tue, 30 Jun 2020 10:47:05 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Eric Rescorla <ekr@rtfm.com>
CC: ADD Mailing list <add@ietf.org>
Thread-Topic: Threat models
Thread-Index: AQHWTwZ4yU9fX8+cxUSRtwVMq+GHUA==
Date: Tue, 30 Jun 2020 17:47:05 +0000
Message-ID: <90DC36D8-6D97-4663-8172-1C7C671B5B41@icann.org>
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com> <bd78f54e-038d-9cff-b6a8-c9c6323ed5f5@redbarn.org> <668384b7-90f5-4ff1-b9e2-d0257aee731d@www.fastmail.com> <3421779.8U4dVgcHlH@linux-9daj> <CABcZeBP8okFjJZk6+PYnTRqDi+KW+=4eT9niRZKkQ00THgL81g@mail.gmail.com> <219413C9-2C0A-45A5-9310-9F044E11D5F0@icann.org> <CABcZeBNNS9cbA4LYkko28y8fMuBHtfEqzb0bRUeytA3JOqkXoA@mail.gmail.com>
In-Reply-To: <CABcZeBNNS9cbA4LYkko28y8fMuBHtfEqzb0bRUeytA3JOqkXoA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_165F0568-0255-4FDC-96DF-F53415D5417F"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/bNHgHSGPfOsyfZYa2a3aXH17w5c>
Subject: [Add] Threat models
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2020 17:47:11 -0000

On Jun 30, 2020, at 10:28 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> With that said, a number of the comments on this proposal have taken the form of "this is inflexible because we want to carry information of type X". I agree that that's technically correct, but the point that I am making (and in fact one that I made when ADD was first chartered) is that proposals that intend to carry other data (such as the URI template of the resolver, for instance) need to document the threat model that they are assuming and demonstrate that they provide some value in that threat model.. That would be true even if we had never submitted this document. What I have seen so far seems insufficient.

Fully agree about "insufficient", including in the drafts I'm co-author on. I don't think each draft should be doing its own threat model because doing so has not led to any agreeemnt in the past, but it might be good if the WG wanted to have that in general.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email