Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

"Salz, Rich" <rsalz@akamai.com> Tue, 27 October 2020 14:52 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65FC3A0B74 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 07:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaQFAlacrukE for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 07:52:19 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB6F3A0B6A for <ietf@ietf.org>; Tue, 27 Oct 2020 07:52:19 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 09REnkrE020494; Tue, 27 Oct 2020 14:52:04 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=m4K2CvF3YWX37FM6ESniff1K3L9f9KhAqrCEdwqWFf4=; b=fz73eZKgBRNak8vb4gVzglyYopa2pavGxedmOXyiCZZSm/JF/ItVHAJcm2dYnkGyQ9mS lirEZuQ2gDQl75ot475qJwJGGw07TipfvZ3J3H/lL8oNv1bPz3GyDGXnPzZ4K+4fPS4h Hk3F8VcsmbpGJ1GEebnMu1dWspESHQiUOYFzcH514MnV6IQi3WyhXR5rKg7IEMG2gWry 1lDf0r2qM6ftWdXZsj9qpr1vSUFcxIppDN46XrVODDmJnx890eNdUxLecYsaA2Laan0b bjGEhMw4tCJVkigk9fIiCZzLJJBipuSZQGQy6hVexWCGGQXpZV3DDMuzKBTkflOEnpbM Ng==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 34ccpbd176-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 14:52:03 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 09REkMMq027160; Tue, 27 Oct 2020 10:52:03 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 34cfkx6kd4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 10:52:03 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 27 Oct 2020 10:52:02 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.007; Tue, 27 Oct 2020 10:52:02 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: Roman Danyliw <rdd@cert.org>, The IETF List <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Thread-Topic: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Thread-Index: Adapa+D5Cfcs8r0xT9Wg091feiESVgCMHiYAABWiuxAAIoqtAP//2K+AgABKfgD//8QnAA==
Date: Tue, 27 Oct 2020 14:52:01 +0000
Message-ID: <C8ED3CFD-47FC-4746-8CE6-ADB48850A7AC@akamai.com>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <09B0A1A1-6534-4A44-A162-9962FFF8D8B8@cisco.com> <362d68dd6117452f925322f8180de423@cert.org> <B864FFAE-3E3E-4CEF-B832-4552C8BAE70B@cisco.com> <11D079DF-614B-44CD-93F4-F53E353E31C7@akamai.com> <20201027142612.GB11207@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20201027142612.GB11207@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-ID: <06583A8537155D4BB219485E8CA6F48E@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-27_08:2020-10-26, 2020-10-27 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 malwarescore=0 suspectscore=0 adultscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010270092
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-27_08:2020-10-26, 2020-10-27 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 spamscore=0 phishscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010270094
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint2
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rQJ5ZPbgKfRA9VCml7Z2dsDWfTI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 14:52:21 -0000

>    So... should the protcol spec have a requirement stating that implementations
    MUST ensure this can not happen, and - oh, go figure out how to do that, not a
    protocol issue ?

I am not sure what you are trying to say.  That it's hard to determine where the fault is sometimes?  I don't think anyone disagrees with that.

I worry about something like "protocol-vulnerabilities@ietf.org" becoming swamped with implementation issues, but I would support this if we agreed it was a two-year experiment or something.

>    In patents, patent protection is only granted when the description is
    sufficient to build a working model. So if you want to claim that a protocol
    is not at fault for an attack, its description needs to be sufficient to
    make it clear how to build a working model protecting against the attack.

Patents (at least in the US) typically have an "escape clause" near the beginning, often written like "As will be readily obvious to one familiar with the field"  So I see the same parallel to standards: avoiding memory exhaustion under load should be readily obvious to one familiar with the field.