Re: [saag] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC

Yakov Shafranovich <yakov@nightwatchcybersecurity.com> Tue, 31 December 2019 02:05 UTC

Return-Path: <yakov@nightwatchcybersecurity.com>
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 <saag@ietfa.amsl.com>; 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 <saag@ietfa.amsl.com>; 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 <saag@ietf.org>; Mon, 30 Dec 2019 18:05:23 -0800 (PST)
Received: by mail-pf1-x443.google.com with SMTP id x6so18006974pfo.10 for <saag@ietf.org>; 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> <CAAyEnSM3TCnLzif1PV4Zs9YOi2p4hj7_MgaCW5rMTE1mFXoxcQ@mail.gmail.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 <yakov@nightwatchcybersecurity.com>
Date: Mon, 30 Dec 2019 21:04:47 -0500
Message-ID: <CAAyEnSMk-0o4A1DEMisuxkadnaoirwaSaT3JDxUmTc6Ft_ByCQ@mail.gmail.com>
To: S Moonesamy <sm+ietf@elandsys.com>
Cc: Security Area Advisory Group <saag@ietf.org>, draft-foudil-securitytxt@ietf.org, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, last-call@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/y8UZXJm76Mh7kX0UfF6NJXsTqxs>
Subject: Re: [saag] Last Call: <draft-foudil-securitytxt-08.txt> (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 <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Dec 2019 02:05:25 -0000

On Sun, Dec 29, 2019 at 4:39 AM S Moonesamy <sm+ietf@elandsys.com> 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!